Remote Procedure Call
In the early 1980s, the Open Software Foundation (now known as The Open Group) developed the RPC network programming standard as part of the Distributed Computing Environment (DCE) distributed computing standard. Microsoft's implementation of RPC is compatible with this original specification.
RPC makes use of other network APIs (e.g., Named Pipes, Message Queuing, or Winsock) in order to provide a programming model that hides most of the details of communicating over a network from the developer. Given that RPC actually rides on top of other APIs, it can use any network transport that those APIs support—it's compatible with any transport on the system.
An RPC app is composed of a series of procedures; some are local, some reside on other machines. To the app, they're all local. Procedures that actually reside on other machines have stub procedures on the local machine that match their calling conventions and parameter lists exactly. The application developer simply calls these routines, not necessarily cognizant of where they physically reside. For basic apps, these stub routines are typically linked statically into the application. For more complex apps, they often reside in separate DLLs. With Distributed COM (DCOM), which uses RPC as its means of executing code on other machines, the stub routines are usually in separate DLLs.
Marshaling
When a stub routine is called, the parameters passed into it must be marshaled for transport across the network to the actual routine. You can think of marshaling as a traffic cop or escort that takes care of the work necessary to route data between different execution contexts. In the case of marshaling between machines, you're obviously routing data from one process to another, so one thing that marshaling must take care of is dereferencing any pointers that are passed into the stub routine, encapsulating the data they reference, and sending it over to the other machine. It has to do this because a pointer in one process isn't going to be useful to another process, particularly if the data it references isn't even there. I like to think of marshaling as the process of taking the data represented by the parameters passed into a routine by the hand and making sure it gets to its destination in a usable form.
When a stub is called, it invokes RPC runtime routines that carry out the work of communicating with the destination computer, negotiating a compatible set of protocols, and sending the request to the other machine. When the destination machine gets the request, it unmarshals the parameters (by placing the encapsulated data back into memory allocations that can then be referenced by the original pointers and fixing up those pointers so that they reference the correct locations) and calls the original procedure with the correct parameter values. All the while, the whole process is transparent to the client-side application code—it simply called a procedure. Once the call completes on the remote system, the whole process is reversed in order to return the results to the caller.
Asynchronous RPC
Windows supports asynchronous RPC as well as synchronous RPC. When an asynchronous RPC is made, the calling app continues to execute. When the call completes, Windows' RPC facility signals an event that was originally associated with the call. The caller can detect this through the traditional means of checking the signal state of a kernel object such as calling WaitForSingleObject.
The RPC Runtime
The RPC runtime resides in Rpcrt4.dll. You can use TList to verify that this DLL is loaded into the SQL Server process space. This DLL is always loaded, regardless of whether SQL Server is configured to listen on the multiprotocol Net-Library, which uses the RPC API. This is because SQL Server's executable directly imports this DLL by name. (You can check this out yourself by using the Depends or DumpBin tools that ship with Visual Studio.)