brad@intek01.UUCP (Brad Held) (07/14/89)
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. The way I see it I have two options. I can either write my own svc_run() and call it, or run a child process that calls svc_run() and have the child pipe the data received to the parent. Is anybody else doing something similar? Which of my two options are you using? Am I all washed up (high probability)? Any information will be greatly appreciated. Thanks in advance Brad Held Software Engineer INTEK Integrated Technologies uunet!intek01!brad
djones@megatest.UUCP (Dave Jones) (07/15/89)
From article <216@intek01.UUCP>, by brad@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.