Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!van-bc!mdavcr!furr
From: furr@mdavcr.UUCP (Steven Furr)
Newsgroups: comp.lang.c++
Subject: Re: C++ classes for Sun RPC
Summary: Yes, I have built one.
Message-ID: <1787@mdavcr.UUCP>
Date: 21 Jun 91 22:10:12 GMT
References: <1991Jun19.192025.14683@colorado.edu>
Organization: MacDonald Dettwiler, 13800 Commerce Parkway, Richmond, BC, Canada  V6V 2J3
Lines: 65

In article <1991Jun19.192025.14683@colorado.edu>, jeffm@noisette.colorado.edu (Jeff McWhirter) writes:
> We have a need for  an   O-O  rpc mechanism in C++ for
> Sun RPC.  It would be nice to support blocking and non-blocking calls,
> xdr routines for passing data, ...?
> It  would also be nice if something like this has been done so we won't
> have to do it.
> Has anyone heard  of or built  such a mechanism???
> 

I saw another that was just posted, but I thought I might describe my own anyway
in case there is interest.  Sorry I can't send out code without approval from
higher-ups.  If you anyone is interested, I will seek approval.

The logical data model for the library is this:

       Sender                            Receiver
	 |                                  |
	 |                                  |
	 -                                  -
	 |                                  |
      Protocol                           Protocol
       Sender                            Receiver
					    ^
					    |
					    v
					 Registry
					    ^
					    |
					    v
					    v
			Protocol <---->> Protocol <<----> Dispatcher
			                 Service
					    ^
					    |
					    v
			Packet   <---->    PAD

The sender and receiver are the classes that encapsulate the transport
mechanism, in this case just TCP.  The ProtocolSender and ProtocolReceiver are
designed to implement a particular protocol.  They can use a different transport
by changing which sender or receiver class they inherit from.

The ProtocolReceiver looks up requests that arrive in the registry to find what
PAD and dispatcher to use.  The PAD is where the XDR routines are kept.
New dispatcher classes are derived to implement each type of service.  The 
dispatcher class provides processor() and post_processor() methods which are
called before and after a reply is sent, respectively.  Messages can be round-
trip or asynchronous; this detail is handled by ProtocolSender and
ProtocolReceiver.

Like everybody else using RPC, I had to tweak the header files. I also made
a minor extension to RPC allowing client data on the svc routines so I could
look up the ProtocolReceiver efficiently.

Contact me for further information.


--
Steve Furr ( furr@mda.ca )

Lesser artists borrow,
great artists steal.

	- blatantly stolen from
	  Igor Stravinsky