RPC to Go v.1

The intent of this post is to give TechNet users a quick overview of RPC.  While it is sometimes hard not to delve into separate parts of RPC, I’ll do my best to keep it short.  Developers should use http://msdn.microsoft.com.

Let’s begin with a list of terms that will be used.

  • Remote Procedure Call (heretofore, RPC) – Inter-process communication technology allowing an application to execute a procedure in another address space.  This can be on the same machine or on another computer.
    • Huh?: For instance, RPC allows one’s Outlook client to talk to an Exchange server…  But if Outlook is installed on the Exchange server, RPC knows to get email locally.
  • Run-time library – Processes requests to and from the client and server stubs…  Gets the client request to the server’s address space whether the server app is local or remote.
  • Client Stub – Handles application requests, translates the parameters into a Network Data Representation (NDR) and makes calls to the run-time library.
  • Server Stub – Handles incoming RPC requests, sends client request to the application.  It then takes the application’s reply, and sends it to the run time library.
  • Transport – Network services used by RPC run-time for node-to-node communications.
  • UUID – Universally Unique Identifier that is specific to each application.
  • End Point Mapper – resolves UUID in client EPM requests to the server app’s registered port and IP address. Applications on the server must register with the EPM.
    • Huh?: The EPM tells the client where to ‘get stuff.’
    • Note: If the client app knows the port and name/IP address of where the server app lives, one may not see a connection made to the endpoint mapper.

How does RPC work?

RPC Process

image

  • A client application calls a local procedure (at least is thinks the procedure is local).  The client stub of the application code reads the called parameters from the client’s address space.  If the call is for a remote procedure the parameters are then transformed into a network data representation (NDR) via marshalling.  The stub call functions in the client’s RPC run-time library.  It appends the RPC Transfer Syntax and sends the procedure call to the remote server.
  • While RPC is transport independent, it must choose a mechanism for sending this data on the wire.  RPC supports UDP, TCP, HTTP and Named Pipes (common).  The decision for sending data isn’t made randomly.  An application developer must specify the network protocol in the application code.
  • If the application is aware of the IP address and port number of the remote server, the client attempts an RPC bind.
  • If IP and port information are not available, the client machine will bind to the endpoint mapper at the remote server. There are three things the client must present to the endpoint mapper.  They are:
    • RPC application UUID
    • The RPC Transfer Syntax (applied via Marshalling)
      • Note: Microsoft has two transfer syntaxes.  All you need to know is the GUID starting with [8A88] represents a 32-bit system’s NDR and a GUID starting with [7171] represents NDR64 for x64 operating systems.
    • The RPC protocol identifier
  • The three items above are the first three floors of what we refer to as the Tower.  Floor 4 will list the EPM port.  Floor 5 will be left open for the EPM to populate with the listening IP and port.
    • Note: Disparate ports and IP addresses must be represented in separate towers.  See my colleague Steve Light’s graphic below:

image

  • With the IP address and listening port at its disposal, the client machine attempts an RPC bind at the server.  After a successful RPC bind (bind_ack) the NDR is passed up to the run-time library.  The run-time library then calls the server stub procedure.  The server stub gets the NDR and translates it and calls an actual procedure on the server.
  • The server side application runs the procedure.  The procedure returns data to the server stub.
  • Like the client stub, the server stub converts the data into NDR that the client stub can read.
  • The server side RPC run-time library sends the data on the wire.
  • The final part of this process is back at the client machine…  The run-time library receives the data.
  • The client stub translates the NDR and passes it to the client’s address space.
  • The client app now functions as if the call was made locally.
    • So, in the Outlook example your inbox would be populated with something by now.

In summary, RPC allows execution of procedures between address spaces.  It differs when the client and server applications are one box as opposed to two. I hope this helps you understand RPC (“to go”) a little better.  Take a few network captures.  You too may get excited about OpNums.

Resources

RPC API http://www.opengroup.org/onlinepubs/9692999399/chap2.htm#tagcjh_05_02_08

RPC on MSDN http://msdn.microsoft.com/en-us/library/aa378651(VS.85).aspx

RPC on TechNet http://technet.microsoft.com/en-us/library/cc774438.aspx

– Rich Chambers