warsaw@nlm.nih.gov (Barry A. Warsaw) (05/16/91)
Has anyone out there tried to write some RPC code using Sun C++ 2.0?
I've found quite a few problems with some of the <rpc/*.h> header
files that come in the C++ distribution. In particular, there are
bogosities in <rpc/pmap_clnt.h>, <rpc/clnt.h>, and <rpc/svc.h>. The
first two I've been able to patch, but I haven't been able to get a
corrected <rpc/svc.h> file to work yet. Note that I'm new to RPC (but
not C++) so I could be doing some things wrong.
Also, even though C++ comes with a version of rpcgen, I've found that
I cannot use the generated files directly, except for the generated
<protocol>.h file. And the C++ rpcgen takes entirely different
switches than "regular" rpcgen. It would be nice if rpcgen(++) where
just a superset of rpcgen!
Does anybody else have similar experiences? Also, does anybody know
if these files have been fixed for 2.1, and if Sun C++ 2.1 FCS is
shipping?
Thanks very much.
-Barry
NAME: Barry A. Warsaw USMAIL: National Library of Medicine
TELE: (301) 496-1936 Lister Hill National Center for
INET: warsaw@nlm.nih.gov Biomedical Communications
UUCP: uunet!nlm.nih.gov!warsaw Information Technology Branch
8600 Rockville Pike
Bldg. 38A, Rm. 7s722
Bethesda, Md. 20894bergquis@nms.gdc.portal.com (Brett Bergquist) (05/20/91)
I to have been trying to get Sun C++ 2.0 to work with RPC. I found the same faults in the header files that you did. I took a different approach by compiling the _svc.c, _xdr.c, and _clnt.c using the C compiler. Somewhere in the manual for C++, it mentioned that you probably want to compile these files with the C compile so that you do not get a lot of warnings. I've noticed that rpcgen++ is not the same as the version that came with with system. In fact, its a revision or so behind. I also found that it has a major bug in that if I retype a basic type, it generates the wrong code. For example: typedef long Mtime; produces typedef u_long *Mtime; For me this was a show stopper. In order to get C++ compatible headers, I fetched a copy of version 3.9 of rpcgen from the net, and modified it myself to support C++. In fact this worked better, because I also modified it to support my error handling mechanisms, coding standards, etc. I've seen a copy of C++ 2.1 and rpcgen++ has been updated to the latest version, without TLI I believe. My Sun salesman said that it has officially been released and is shipping, but I am still waiting for our systems administrator to get it. -- Brett M. Bergquist, Principal Engineer | "Remind me" ... "to write an General DataComm, Inc., | "article on the compulsive reading Middlebury, CT 06762 | of news." - Stranger in a Strange Land Email: bergquis@nms.gdc.portal.com or ...!portal!gdc!nms!bergquis
warsaw@nlm.nih.gov (Barry A. Warsaw) (05/23/91)
>>>>> "Brett" == Brett Bergquist <bergquis@nms.gdc.portal.com> writes: Brett> I to have been trying to get Sun C++ 2.0 to work with RPC. Brett> I found the same faults in the header files that you did. Brett> I took a different approach by compiling the _svc.c, Brett> _xdr.c, and _clnt.c using the C compiler. Somewhere in the Brett> manual for C++, it mentioned that you probably want to Brett> compile these files with the C compile so that you do not Brett> get a lot of warnings. Well, after a bit of hacking (at patching the Sun C++ 2.0 header files), I've finally got a couple of classes implementing RPC. I took the files generated by rpcgen (not rpcgen++) as a template and wrapped it all up into a `server' and `client' class. One limitation is that I only implemented tcp since that's what I'm using, but there's nothing to prevent you from extending/modifying the class internals. Below are the public interfaces to the two classes. You'll still need rpcgen to create the _xdr.c file and the <protocol>.h file if you don't do it by hand (which really is almost as easy, except there's more to maintain when the protocol changes). If you're interested in more details send email. `server' usage requires you to derive your own class from server and make member functions of this class take two char*& arguments. These member functions will be the callback associated with RPC procedure numbers. The two char*& arguments can be cast to pointers to the appropriate data type within the callback function. Allocation and de-allocation of memory, serializing and deserializing XDR streams, etc, are all handled internally, as well as registration with portmapper and other bookkeeping. `client' usage more straightforward. You just give it a server hostname to connect to and then remotely execute procedures. You give rexec the size of the receiving data type (out) so that it is zeroed out before the deserialized data is placed there. -Barry NAME: Barry A. Warsaw USMAIL: National Library of Medicine TELE: (301) 496-1936 Lister Hill National Center for INET: warsaw@nlm.nih.gov Biomedical Communications UUCP: uunet!nlm.nih.gov!warsaw Information Technology Branch 8600 Rockville Pike Bldg. 38A, Rm. 7s722 Bethesda, Md. 20894 ==================== server class ==================== typedef void (server::*rpc_handler)( char*& in, char*& out ); class server { public: // it is an error to instantiate more than 1 instance of the // server class. Note that there is no destructor for this // class since (due to the nature of the run method), it will // never be destroyed until the entire process dies. server( u_long prognum, u_long versnum ); // register an RPC procedure with the appropriate callback // function which can handle this procedure call. void regproc( u_long procedure, rpc_handler callback, xdrproc_t in_converter, int indata_size, xdrproc_t out_converter, int outdata_size ); // once all callbacks are registered, the application can call // the run method below to start up the RPC server. it is an // error for run() to ever return so if a callback is used to // terminate the server, it should call exit() inline void run( void ); // returns non-zero if the application was started up by the // inet daemon inline int inetd_p( void ); protected: // this function actually does the dispatching to the member // function that can handle the remote procedure call. it is // not directly called by the RPC level code. virtual void dispatch( svc_req* request, SVCXPRT* transp ); }; ==================== client class interface ==================== static timeval _DEFAULT_CLIENT_TIMEOUT = { 25, 0 }; class client { public: inline client( string server, u_long prognum, u_long versnum, timeval timeout = _DEFAULT_CLIENT_TIMEOUT ); inline ~client( void ); // execute remote procedure on server, returns zero on // success, non-zero on failure. inline int rexec( u_long procedure, xdrproc_t in_converter, char*& in, xdrproc_t out_converter, char*& out, int sizeof_outdata ); // get and set the timeout value inline void timeout( timeval& new_timeout ); inline timeval timeout( void ); };