[comp.sys.sun] Seeking RPC and XDR information

miket@ames.arc.nasa.gov (Michael Thompson) (07/08/89)

Greetings everyone,

I would like to find out if there are any public domain implementations of
Suns RPC (Remote Proceedure Call) and XDR (External Data Representation)
protocols for any operating system.  According to our Sun represenative,
the protocol specifications are available publicly (I have the specs. in
the manual 'Networking on the Sun Workstation'), but we require a SunOS
and AT&T Unix source licences to get the actual implementation source
code.

I am trying to see how feasable it would be to create an ethernet device
which would be controlled by RPC calls from a remote Sun workstation.  RPC
and XDR will have to be embedded in the firmware on the device.  I know I
can come up with compatible routines from the specifications provided by
Sun, but example source code from someone else's RPC and XDR
implementation would make the task a whole lot easier.  Examples of RPC
implemented over UDP/IP or TCP/IP on an MS/DOS based machine would be
ideal. 

I would be extremely grateful for any leads someone can give me in this 
area.  Also any general comments on RPC would be welcome. 

Thanks, 

Mike Thompson
=========================================================================
Michael P. Thompson                                Bell Northern Research 
Member Scientific Staff                          685A E. Middlefield Road
(415) 940-2575                                          Mountain View, CA
amdahl!bnrmtv!miket                                            94039-7277

marks@sun.com (Mark Stein) (07/18/89)

>From a message in Sun-Spots Digest, v8n67:

> I would like to find out if there are any public domain implementations of
> Suns RPC (Remote Proceedure Call) and XDR (External Data Representation)
> protocols for any operating system.  According to our Sun represenative,
> the protocol specifications are available publicly (I have the specs. in
> the manual 'Networking on the Sun Workstation'), but we require a SunOS
> and AT&T Unix source licences to get the actual implementation source
> code.

As longtime readers of Sun-Spots know, this statement by the Sun
representative is incorrect.  The code is freely available from Sun, and
has been posted to the net several times.  And is available in the
Sun-Spots archive.  There is a license required for the full ONC/NFS
source, but no licenses are required for RPC/XDR source.

I have sent a message to Sun field technical people to clear this up.

Mark Stein <marks@sun.com>
Sun Microsystems, Inc.

brent@uunet.uu.net (Brent Chapman) (07/19/89)

# I would like to find out if there are any public domain implementations of
# Suns RPC (Remote Proceedure Call) and XDR (External Data Representation)
# protocols for any operating system.  According to our Sun represenative,
# the protocol specifications are available publicly (I have the specs. in
# the manual 'Networking on the Sun Workstation'), but we require a SunOS
# and AT&T Unix source licences to get the actual implementation source
# code.

Bullshit.  Yet another case of the Sun sales reps not knowing what their
own company is doing, and giving an authoritative and _incorrect_ answer
when they _should_ be saying "I don't know, but here's the Sun technical
person you should contact.".

A while back (late 1987), Sun posted sources to RPC Version 3.9 to the
comp.sources.unix USENET newsgroup.  These sources are available from the
comp.sources.unix archive on UUNET (anonymous FTP to uunet.uu.net; the
files you want are in comp.sources.unix/volume13/rpc3.9/part[01-15].Z).

At the time these sources were released, RPC v3.9 was a _later_ version of
RPC (with substantially greater capabilities) than the binaries being
shipped with the then-current version of SunOS (3.4 or 3.5, I think).  The
version of RPC shipped with SunOS 4.0 appears to be slightly later than
the source version, but I don't think any features have been added.

The contact person at Sun for all this is (or at least was, at the time
the stuff was released) Steve Nahm <sxn@sun.com>.

It's very hard to get reliable, accurate, timely, detailed technical
information out of the Sun sales and sales support staff.  They don't know
the answers, and apparently don't know who inside Sun to ask (note that
this isn't necessarily the fault of the sales force, though).  I consider
this a problem second only to the current abysmal state of Sun's software
support services.  I've given up on trying to get answers to technical
questions like this through "official" channels, and instead rely on the
net and my own personal contacts at Sun.

Brent

Brent Chapman					Capital Market Technology, Inc.
Computer Operations Manager			1995 University Ave., Suite 390
brent@capmkt.com				Berkeley, CA  94704
{apple,lll-tis,uunet}!capmkt!brent		Phone:  415/540-6400

sow@eru.luth.se (Sven-Ove Westberg) (07/28/89)

In article <383@brazos.Rice.edu> capmkt!brent@uunet.uu.net (Brent Chapman) writes:
|RPC (with substantially greater capabilities) than the binaries being
|shipped with the then-current version of SunOS (3.4 or 3.5, I think).  The
|version of RPC shipped with SunOS 4.0 appears to be slightly later than
|the source version, but I don't think any features have been added.
|

Version RPC version 4.0 is available for anonymous ftp from
eru.mt.luth.se.

This is the README file from the distribution.


================ DISCLAIMER ================
/*
 * Sun RPC is a product of Sun Microsystems, Inc. and is provided for
 * unrestricted use provided that this legend is included on all tape
 * media and as a part of the software program in whole or part.  Users
 * may copy or modify Sun RPC without charge, but are not authorized
 * to license or distribute it to anyone else except as part of a product or
 * program developed by the user.
 * 
 * SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING THE
 * WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE.
 * 
 * Sun RPC is provided with no support and without any obligation on the
 * part of Sun Microsystems, Inc. to assist in its use, correction,
 * modification or enhancement.
 * 
 * SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE
 * INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY SUN RPC
 * OR ANY PART THEREOF.
 * 
 * In no event will Sun Microsystems, Inc. be liable for any lost revenue
 * or profits or other special, indirect and consequential damages, even if
 * Sun has been advised of the possibility of such damages.
 * 
 * Sun Microsystems, Inc.
 * 2550 Garcia Avenue
 * Mountain View, California  94043
 */


================   README   ================
RPCSRC 4.0 8/11/88

This distribution contains Sun Microsystem's implementation of the
RPC and XDR protocols and is compatible with 4.2BSD and 4.3BSD.  Also
included is complete documentation, utilities, RPC service
specification files, and demonstration services in the format used by
the RPC protocol compiler (rpcgen).  See WHAT'S NEW below for
details.

NOTE ABOUT SECURE RPC:

This release of RPCSRC contains most of the code needed to implement
Secure RPC (see "DES Authentication" in the RPC Protocol Specification,
doc/rpc.rfc.ms).  Due to legal considerations, we are unable to
distribute an implementation of DES, the Data Encryption Standard, which
Secure RPC requires.  For this reason, all of the files, documentation, and
programs associated with Secure RPC have been placed into a separate
directory, secure_rpc.  The RPC library contained in the main body of this
release *DOES NOT* support Secure RPC.  See secure_rpc/README for more
details.

If you wish to report bugs found in this release, send mail to:

Portable ONC/NFS
Sun Microsystems, Inc
MS 12-33
2550 Garcia Avenue
Mountain View, CA  94043

or send Email to nfsnet@sun.com (the Internet) or sun!nfsnet (Usenet).

ROADMAP

The directory hierarchy is as follows:

    demo/       Various demonstration services
    demo/dir        Remote directory lister
    demo/msg        Remote console message delivery service
    demo/sort       Remote sort service

    doc/        Documentation for RPC, XDR and NFS in "-ms" format.

    etc/        Utilities (rpcinfo and portmap).  portmap must be
                started by root before any other RPC network services are
                used.  SEE BELOW FOR BUGFIX TO 4.3BSD COMPILER.

    man/        Manual pages for RPC library, rpcgen, and utilities.

    rpc/        The RPC and XDR library.  SEE BELOW
                FOR BUGFIX TO 4.2BSD COMPILER.

    rpcgen/     The RPC Language compiler (for .x files)

    rpcsvc/     Service definition files for various services and the
                server and client code for the Remote Status service.

    secure_rpc/ The files in this directory are used to build a version of
                the RPC library with DES Authentication.  See the README
                file in that directory for more details.

BUILD INSTRUCTIONS

Makefiles can be found in all directories except for man.  The
Makefile in the top directory will cause these others to be invoked
(except for in the doc, man and demo directories), in turn building the
entire release.

WARNING!  THE DEFAULT INSTALLATION PROCEDURES WILL INSTALL FILES
IN /usr/include, /usr/lib, /usr/bin and /etc.

After making any compiler fixes that are needed (see below), at
the top directory, type:

    make install

For all installations, the Makefile macro DESTDIR is prepended to the
installation path.  It is defined to be null in the Makefiles, so
installations are relative to root.  (You will probably need root
privileges for installing the files under the default path.)  To
install the files under some other tree (e.g., /usr/local), use the
command:

    make install DESTDIR=/usr/local

This will place the include files in /usr/local/usr/include, the RPC
library in /usr/local/usr/lib, rpcgen in /usr/local/usr/bin, and the
utilities in /usr/local/etc.  You'll have to edit the Makefiles or
install the files by hand if you want to do anything other than this
kind of relocation of the installation tree.

The RPC library will be built and installed first.  By default it is
installed in /usr/lib as "librpclib.a".  The directory
/usr/include/rpc will also be created, and several header files will
be installed there.  ALL RPC SERVICES INCLUDE THESE HEADER FILES.

The programs in etc/ link in routines from librpclib.a.  If you change
where it is installed, be sure to edit etc/'s Makefile to reflect this.
These programs are installed in /etc.  PORTMAP MUST BE RUNNING ON
YOUR SYSTEM BEFORE YOU START ANY OTHER RPC SERVICE.

rpcgen is installed in /usr/bin.  This program is required to build
the demonstration services in demo and the rstat client and server in
rpcsvc/.

The rpcsvc/ directory will install its files in the directory
/usr/include/rpcsvc.  The Remote Status service (rstat_svc) will be
compiled and installed in /etc.  If you wish to make this service
available, you should either start this service when needed or have
it started at boot time by invoking it in your /etc/rc.local script.
(Be sure that portmap is started first!)  Sun has modified its
version of inetd to automatically start RPC services.  (Use "make
LIB=" when building rstat on a Sun Workstation.)  The Remote Status
client (rstat) will be installed in /usr/bin.  This program queries
the rstat_svc on a remote host and prints a system status summary
similar to the one printed by "uptime".

The documentation is not built during the "make install" command.
Typing "make" in the doc directory will cause all of the manuals to
be formatted using nroff into a single file.  We have had a report
that certain "troff" equivalents have trouble processing the full
manual.  If you have trouble, try building the manuals individually
(see the Makefile).

The demonstration services in the demo directory are not built by the
top-level "make install" command.  To build these, cd to the demo
directory and enter "make".  The three services will be built.
RPCGEN MUST BE INSTALLED in a path that make can find.  To run the
services, start the portmap program as root and invoke the service
(you probably will want to put it in the background).  rpcinfo can be
used to check that the service succeeded in getting registered with
portmap, and to ping the service (see rpcinfo's man page).  You can
then use the corresponding client program to exercise the service.
To build these services on a Sun workstation, you must prevent the
Makefile from trying to link the RPC library (as these routines are
already a part of Sun's libc).  Use: "make LIB=".

BUGFIX FOR 4.3BSD COMPILER

The use of a 'void *' declaration for one of the arguments in
the reply_proc() procedure in etc/rpcinfo.c will trigger a bug
in the 4.3BSD compiler.  The bug is fixed by the following change to
the compiler file mip/manifest.h:

*** manifest.h.r1.1	Thu Apr 30 13:52:25 1987
--- manifest.h.r1.2	Mon Nov 23 18:58:17 1987
***************
*** 21,27 ****
  /*
   * Bogus type values
   */
! #define TNULL	PTR		/* pointer to UNDEF */
  #define TVOID	FTN		/* function returning UNDEF (for void) */

  /*
--- 21,27 ----
  /*
   * Bogus type values
   */
! #define TNULL	INCREF(MOETY)	/* pointer to MOETY -- impossible type */
  #define TVOID	FTN		/* function returning UNDEF (for void) */

  /*

If you cannot fix your compiler, change the declaration in reply_proc()
from 'void *' to 'char *'.

BUGFIX FOR 4.2BSD COMPILER

Unpatched 4.2BSD compilers complain about valid C.  You can make old
compilers happy by changing some voids to ints.  However, the fix to
the 4.2 VAX compiler is as follows (to mip/trees.c):

*** trees.c.r1.1	Mon May 11 13:47:58 1987
--- trees.c.r1.2	Wed Jul  2 18:28:52 1986
***************
*** 1247,1253 ****
  		if(o==CAST && mt1==0)return(TYPL+TYMATCH);
  		if( mt12 & MDBI ) return( TYPL+LVAL+TYMATCH );
  		else if( (mt1&MENU)||(mt2&MENU) ) return( LVAL+NCVT+TYPL+PTMATCH+PUN );
! 		else if( mt12 == 0 ) break;
  		else if( mt1 & MPTR ) return( LVAL+PTMATCH+PUN );
  		else if( mt12 & MPTI ) return( TYPL+LVAL+TYMATCH+PUN );
  		break;
--- 1261,1269 ----
  		if(o==CAST && mt1==0)return(TYPL+TYMATCH);
  		if( mt12 & MDBI ) return( TYPL+LVAL+TYMATCH );
  		else if( (mt1&MENU)||(mt2&MENU) ) return( LVAL+NCVT+TYPL+PTMATCH+PUN );
! 		/* if right is TVOID and looks like a CALL, is not ok */
! 		else if (mt2 == 0 && (p->in.right->in.op == CALL || p->in.right->in.op == UNARY CALL))
! 			break;
  		else if( mt1 & MPTR ) return( LVAL+PTMATCH+PUN );
  		else if( mt12 & MPTI ) return( TYPL+LVAL+TYMATCH+PUN );
  		break;

WHAT'S NEW IN THIS RELEASE: RPCSRC 4.0

The previous release was RPCSRC 3.9.  As with all previous releases,
this release is based directly on files from Sun Microsystem's
implementation.

Upgrade from RPCSRC 3.9

1)  RPCSRC 4.0 upgrades RPCSRC 3.9.  Improvements from SunOS 4.0 have
    been integrated into this release.

Secure RPC (in the secure_rpc/ directory)

2)  DES Authentication routines and programs are provided.
3)  A new manual, "Secure NFS" is provided, which describes Secure RPC
    and Secure NFS.
4)  Skeleton routines and manual pages are provided which describe the
    DES encryption procedures required by Secure RPC.  HOWEVER, NO DES
    ROUTINE IS PROVIDED.

New Functionality

5)  rpcinfo can now be used to de-register services from the portmapper
    which may have terminated abnormally.
6)  A new client, rstat, is provided which queries the rstat_svc and
    prints a status line similar to the one displayed by "uptime".


===========================================================================

Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
Tel:     +46-920-91677  (work)                 +46-920-48390  (home)
Internet: sow@cad.luth.se