Need deeper info about RPC paradigm

Question

Having scoured the Web for info about RPC, I find the same few discussions repeated widely, but certain things left unexplored. I therefore have particular questions that remain unanswered.
1) RPC server behavior appears predicated around "connect-call-disconnect, connect-call-disconnect, ..." behavior on the part of the RPC client; that is, a connect-and-disconnect around every remote procedure call. I, on the other hand, need my clients to implement "connect-wait-call-wait-call-wait-call-...-disconnect" behavior; that is, to connect, REMAIN connected for an extended period of time across multiple procedure calls, and disconnect only when the client is ready to terminate all use of the server. It appears that svc_run() supports this, but I want to avoid surprises; is there any restriction on this usage of svc_run()? Can this paradigm be supported by appropriate use of the RPC library routines available for replacing svc_run() with my own code?
2) The only "documentation" I have been able to find about how to write actual RPC programs dates back to 1992 and does not come from Sun. Virtually all of the routines appearing in its example programs are designated "obsolete" or "for backward compatibility" in their manpages on Solaris 8. Can you recommend/point to an instructional text that describes RPC programming as it would be done with "today's" interface?
3) Probably the largest single obstacle to my organization's possible use of RPC in "real," critical applications, is RPC's continuing C-specificity. We write all our applications in C++, and mostly object-oriented C++ at that -- whereas RPC appears not to have advanced beyond the "C with global variables" architecture (with one possible exception, following). Code generated by RPCGEN (without the -C switch, I admit; I haven't gotten that far in my trial-and-error experiments, yet) requires extensive hand-editing in order to compile C++ code that uses it, or link successfully with compiled C++ code. This obstacle is severe enough to potentially render RPC an unacceptable solution for us.
The possible exception I mentioned is that I found a webpage that discussed something called 'rpcc,' which appeared to be an object-oriented, C++ implementation of RPC. The page said this was available "on Sun machines," but I don't find it on MY Sun machines. Other searches do not turn up other references. Such a thing would be a godsend if it existed, and it would seem not to be so difficult for Sun's professional developers to create. So does it exist? If so, how can I get my hands on it?
4) Different sources contradict each other as to the "semantics" of an RPC procedure call. Sun's ONC manual says flat-out that Sun RPC provides only "at least once" semantics -- but then, the manual takes the approach that one is using RPC in a "transport-independent" manner. Other references discuss the issue at greater length (hint, hint) and imply that any RPC implementation can provide "exactly once" semantics, providing that one specifically force it to use "a reliable transport such as TCP." It is not clear how much to infer, or disregard, in Sun's simple statement. I need to know FOR SURE whether Sun RPC can be made, forced, tricked, etc. into providing "exactly once" semantics. If so, is "use of TCP" sufficient? Or are other tricks needed? Please outline the necessary steps that might be needed in addition to using TCP.
5) (Related to 4. Sun documentation contains language to the effect that Sun RPC provides "at least once" semantics because providing "exactly once" semantics "would be too difficult." However, a graduate student (at Syracuse U if I recall correctly) posts a research paper in which he describes an RPC facility, developed from scratch, that provides "exactly once" semantics. Apparently it's not THAT difficult, after all. The fact that it's "too difficult" for Sun does not exactly flatter the company. They may want to revisit this, and provide yet another RPC interface (in C++ while they're at it). I won't even charge a finder's fee. ;-) )
Thanks in advance,
Chris

Answer 1

I agree fully.
None of the example code applies to todays
"real-world" applications. Im trying to implement
multithreaded RPC on Solaris using rpcgen's -N
"NewStyle", -A "Auto multithreaded" and -C "ANSI C"
options but none of the examples anywhere show how to
do this. Is their a better technology that everyone
is using now that does a similar thing?I have an example that might help. It's a multi-threaded
NIS server that's been running in production for several
years. There are a few tricks in the source that might help.
You can download the source with anonymous FTP at
ftp.cc.umanitoba.ca. Look in the `src' directory for
midas.tar.Z.