From wesommer@athena.MIT.EDU Sat Aug 9 15:24:54 1986
To: hackers@athena.MIT.EDU, kerberos@athena.MIT.EDU
Subject: SUN RPC & XDR
Date: Sat, 09 Aug 86 15:22:07 -0500
From: Bill Sommerfeld < wesommer@athena.MIT.EDU>
I just found the posting of the SUN Remote Procedure Call library on
mod.sources. Sources (which have been slighly hacked to get them to
work) are in /@/priam/mit/w/e/wesommer/rpc. I've already psroff'ed
the documents; if you want a copy, I'll lend you the one I printed for
The system is set up to allow RPC over both TCP and UDP, and provides
a dynamic port-mapper daemon to map "program numbers" to UDP ports.
RCP calls are uniquely identified by a (program number, version
number, procedure number) tuple. SUN will "register" program numbers
from 0x00000000 to 0x1fffffff; they allocate 0x20000000 to 0x3fffffff
to "customer specific applications", and 0x40000000 to 0x5fffffff for
dynamically allocated program numbers.
SUN RPC attempts to solve the data representation and transport
problem; it does not attempt to solve the rendezvous problem (clients
have to know which machine their server is on, and which program
number, version number, and procedure numbers it is listening for).
Data representation is done through what they call XDR ("eXternal Data
Representation"); each type provides an "xdr" operation, which walks
the data structure, calling the xdr operations of its components.
Depending on the state of the XDR "stream" passed in, this either
builds a data structure from a stream of bytes, sends it over RPC,
flattens it into a stream of bytes, or destroys the data structure.
There are hooks for arbitrary authentication; I think I have
implemented the proper ones for Kerberos, (look at the routines in
rpc/rpclib/*krb*) although since kerberos.mit.edu is down right now, I
can't test this.
Since the authenticator is decyphered by the server-side library
before the service is identifed, a catch-all "rpc" or "sunrpc"
principal for each host involved will be needed to get this to work.
There may be a way around this if we're not afraid to do some sort of
"modularity violation" in the Kerberos-specific code.