How RPC Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How RPC Works

In this section

• RPC Architecture

• RPC Processes and Interactions

• Network Ports Used by RPC

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
Client or server process	Program or service that initiates or responds to an RPC request.
RPC stubs	Program subsystems used by a client or server to initiate an RPC request.
Marshalling engine (NDR20 or NDR64)	Provides a common RPC interface between RPC clients and servers. NDR20 is used 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 programming interface (API)	Provides a direct interface for RPC to clients or servers. RPC clients and servers typically call the runtime API to initialize RPC and prepare the data structure that is 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 protocol engine	Used when the RPC requires a connection–oriented protocol. This layer designates the connection–oriented protocol to use if the RPC is outgoing or receives an incoming connection–oriented RPC.
Datagram RPC protocol engine	Used when the RPC requires a connectionless protocol. This layer designates the connectionless protocol to use if the RPC is outgoing or receives an incoming connectionless RPC.
Local RPC protocol engine	Used when the server and client are located on the same host.
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, advapi32.dll, ntdll.dll)	Kernel32.dll is a Windows NT base API client dynamic-link library (DLL) file that provides system services for managing threads, memory, and resources. Advapi32.dll is an advanced Windows 32 base API DLL file; it is an API services library that supports security and registry calls. Ntdll.dll is an NT layer DLL file that controls Windows NT system functions.
SSPI (secur32.dll)	Provides a security interface for RPC. Negotiates the use of Kerberos, NTLM, or Secure Sockets Layer (SSL) for authentication and encryption.
Endpoint Mapper (EPM) (rpcss.dll)	Rpcss.dll primarily provides the infrastructure for COM, but a portion of rpcss.dll is used for the EPM. An RPC server contacts the EPM to receive dynamic endpoints and 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.

RPC Processes and Interactions

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.

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

Network Ports Used by RPC

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.

Port Assignments for RPC

Service Name	UDP	TCP
HTTP	80, 443, 593	80, 443, 593
Named Pipes	445	445
RPC Endpoint Mapper	135	135
RPC Server Programs	<Dynamically assigned>	<Dynamically assigned>