SunOS RPC babe in the woods seeks counsel ...

Dave Jones djones at megatest.UUCP
Sat Jul 15 08:27:38 AEST 1989


>From article <216 at intek01.UUCP>, by brad at intek01.UUCP (Brad Held):
> 
> I am very new to RPC programming and have an implementation question.
> 
> What I want to do: Have a program that can do more than just act as an
> 	RPC server.
> 
> My "problem": Calling svc_run() never returns, which obviously means
> 	that I can do nothing else.
> 
...
> Am I all washed up (high probability)?
> 

You're not all washed up. Just sort of spot cleaned here and there.

Look up svc_getreq() and select().  You use select() to know when
a message comes in (or the "notifier", if you are using a dispatch-library),
and you use svc_getreq() to handle the message. You can use select() either to
wait for messages, or to poll for them. The manual explains how.

Now for some editorializing: Are you really really sure that RPC is the
right tool for what you are doing? It is an awful lot of complexity for
only a little bit of functionality. It can be extremely difficult
to debug. And the XDR stuff is not what it is cracked up to be.
I'm a big fan of *text* for external data representation. Makes it easy to
convert between ASCII and EBCDIC -- just filter the whole thing --
and there's no big/small endian nonsense. XDR makes no provision whatsoever
for EBCDIC, and their "standard" for byte-order, floating point
representation, etc. is, (by some remarkable coincidence), exactly the 
memory image of the internal representation in Sun workstations. So if you
have to port it to an enemy computer, you have to write routines which
convert to and from Sun's format. There is the ntoh and hton stuff which
will help with byte-order, but the floating point can be verrrry tedious.

If you use text, you get the converion routines for free: printf, scanf,
etc...

For most applications, the size of the data will not be critical.
Even if it is, sometimes the text will actually be smaller than binary (small
numbers require only an eight-bit char, not a 32 bit integer), but even
if text is too big, "compress" and "uncompress" may save you.



More information about the Comp.unix.wizards mailing list