Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.lang.c++
Subject: Re: C++ classes for Sun RPC
Message-ID: <19176@prometheus.megatest.UUCP>
Date: 25 Jun 91 00:27:53 GMT
References: <1787@mdavcr.UUCP>
Organization: Megatest Corporation, San Jose, Ca
Lines: 50

A few years ago, I did built a remote object facility using RPC. It's
written in C.

I didn't use much of the RPC layer per se, but because of a pre-existing
application, I did use the underlying XDR.

My system, which is still in use, centers around a daemon which performs
name-server kinds of services.  Server programs in the domain must register
with this daemon to advertize either that they contain static
object, or that they can construct a new object of a given class.
This rendesvous also creates a map from class-names and member-function
names to numbers, which are used in the actual transactions between client and
server. Client programs request "handles" on objects, which are thereafter
used when invoking member-functions in the server. The handle is an
"opaque" pointer to a data-structure describing the network connection,
the member-function info, et cetera. If the request is for a new object,
the daemon automatically invokes a constructor registered by
the server, which returns info to identify the new object subsequently.
After the initial connection, the daemon does not take part in the further
transactions. Library code on the client side does a name-to-number
translation which users do not need to know about. It is really very easy
to use.

Now the bad news.

Because of another existing application, I had to hack the Sun RPC library
so that calls could be made which did not block awaiting an acknowlegement.
Or at least I thought I had to. It would have been better perhaps to have
used an "almost always ready" daemon to queue up the rpc calls to this one
application, but at the time we needed all the speed we could get, so I
let the TCP layer handle the queuing.

I've run into trouble now because yet another application uses the
standard Sun release of RPC independantly from my hacked version. (It
should not, because the standard server makes resources available on
a machine-by-machine basis. There is no other concept of a process-domain,
which makes it impossible to run two of these multi-process programs on
the same machine. But that's another story.) The problem I am facing right now
is that Sun has made an incompatible change to the semantics of XDR as
released for the SPARC, removing the documented variable "svc_fds". I think
the mc68 version that we have still uses the variable. I haven't yet decided
what I'm going to do about that.

If I had it to do again, I would not use RPC or XDR. Neither protocol
brings enough to the party to justify its existence. Of course I would
also use C++ rather than C. When I did this before, C++ was not available.
Rather than using ascii names, I probably would come up with some kind
of automated "stub-procedure" building program, to build member-functions
that look to the user as though they are the regular kind. Their "this"
pointer would be the handle which I described.