RPC to Go v.1

RPC to Go v.1

  • Comments 6
  • Likes

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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • quote:

    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.

    :endquote

    Outlook cannot be installed on an exchange server:

    http://support.microsoft.com/kb/266418

    You might want to use file sharing or remote registry service as an example.

  • Eric,

    Thanks for your input. While Outlook "should not" be installed on the same computer as Exchange, it can be. It isn't a supported configuration scenario other than for test purposes--that should be noted.

    File sharing wouldn't be a good example of RPC. The protocol used most in Windows is SMB. With Server 2008 and Vista we also use the WebDav protocol for file transfers.

    Remote registry/remote computer management will use Named Pipes.

    Thank again for the input.

    -Rich Chambers

  • Thanks for the great article. For some reason discussions of RPC always made me say - Huh?

    It would be great if you could include a concrete example, like Outlook in Cached Exchange Mode. Then the abstract concepts might not make my eyes glaze over ;-)

  • This post is an update to “ RPC to Go v.1 .”  I assume that you have read v.1 and have

  • Was really understandable , and knowledegable.

    Got teh hack of this eaisly and may researh it more on this

  • In this blog I’d like to give some information on what Named Pipes are, what a Named Pipes connection