How RPC Works

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 5

How RPC Works

Updated: March 28, 2003

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 Program or service that initiates or responds to an RPC request.


process

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.

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>

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy