MSRPC2 is a Remote Procedure Call system designed to run over the Multi-Service Network Architecture. At the low level it is very lightweight: bindings are implicitly single-threaded and are in one-to-one correspondence with lightweight virtual circuits. Interface references are also single-protocol affairs. At the higher levels it is based on some aspects of the ANSA Computational Model and borrows a number of ideas from the DEC SRC Modula-3 Network Objects system. It also incorporates transparent optimisations for calls within a single address space (for use in shared libraries) which map invocations onto single procedure calls.
MSRPC2 was written by Simon Crosby and Timothy Roscoe as an attempt to correct many of the grosser shortcomings of MSRPC, which itself was based heavily on SUN RPC. While the wire representation of MSRPC2 is very similar (the only obvious difference being the use of procedure numbers to represent exceptions), the tale grew in the telling. There is a totally new stub compiler based on MIDDL (a minor extension of ANSA IDL), the marshalling code has been rewritten from the ground up, and the run-time system has been completely re-implemented over the POSIX pthreads interface. Other implementations to run over raw Wanda threads, both inside and outside the kernel, are anticipated.
To understand this manual, it helps to have had some experience with ANSAware and/or Modula-3 Network Objects. It is essential to have a knowledge of the interface definition language, though a working knowledge of ANSA IDL might do. You have to know what an RPC system looks like.
The structure of the system splits quite nicely into layers and much of this manual is organised into chapters about the various layers and the interfaces between them. Broadly speaking, from the top down:
This is the code that the user writes, whether as a client or a provider of a particular service. The key concepts are those of interfaces and bindings.
A service provider creates an interface by instantiating a particular interface type. This operation returns a handle on the interface itself (used for shutting it down), and an interface reference to be used for naming the interface to remote clients.
A client in possession of a reference for an interface can attempt to bind to it. This operation returns a binding which appears to be an abstract data type: operations on a binding are restricted to the methods it provides. These are the operations defined in the interface specification, plus ones for setting protocol-specific aspects of the binding connection, and ultimately shutting it down.
A request from a client to bind to an interface results in the creation of a similar binding at the server end. Server code also initialises state it can hold on a per-binding (per-client) basis (or refuse the bind request if it so desires). Servers can also alter protocol-specific aspects of the binding and destroy the binding themselves.
Unlike many RPC systems, there can be many interfaces active in a single server process. These interfaces can be of arbitrary types. Interfaces of the same type in a single server process can have different implementations.
The stub code is generated from the interface specification by the stub compiler. It is the portion of the system that is specific to a given interface type, and the only portion of the system that user code needs to interact with. It consists of type definitions for use by client and server user code and library routines to create and destroy interfaces and bindings, along with the stubs which make remote invocations and exceptions look like their local equivalents.
The marshalling code is also partially generated by the stub compiler; for each data type defined in an interface it provides C functions or macros for marshalling an instance of the type into a buffer, unmarshalling it into user memory, and freeing up memory which may have been allocated to hold entities whose size the user cannot know in advance. MSRPC2 allows user code considerable control over where data are unmarshalled and how the marshalling code allocates memory for them.
The runtime system is a library which handles all network transmission of packets, timeouts and the like. See a later section.
The wire representation is the format of data in the packets sent between machines in the course of an invocation. MSRPC2 uses a data representation called MSDR, which is based in on XDR used by Sun RPC.