gaf@uucs1.UUCP (gaf) (07/31/90)
I'm rather a novice at this remote procedure call stuff (Sun RPC variety), and am looking for reference material. The documentation which comes from our vendor(s) covers the basics well enough to get some simple-minded applications going, but I'd like to streamline them a bit. For example, where I'm currently returning fixed-size arrays back to the client, I'd rather return a variable-length array, with variable length strings in it. The docs I have don't get into this sort of thing, nor into the mysteries of passing lists & trees (pointers) between server and client. The bookstores around here don't have any titles on the subject, so I'm looking for some pointers to reading material from you old pros (emphasis on "pro", not "old"). -- Guy Finney It's that feeling of deja-vu UUCS inc. Phoenix, Az all over again. ncar!noao!asuvax!hrc!uucs1!gaf sun!sunburn!gtx!uucs1!gaf
joshua@athertn.Atherton.COM (Flame Bait) (08/03/90)
In article <296@uucs1.UUCP> gaf@uucs1.UUCP () writes: >I'm rather a novice at this remote procedure call stuff (Sun RPC variety), >and am looking for reference material. > >The bookstores around here don't have any titles on the subject, so I'm >looking for some pointers to reading material from you old pros >(emphasis on "pro", not "old"). Get a copy of the SunOS 4.1 documenation for RPC. I thought it was much better than the stuff available with 3.X. Also, Springer-Verlag has a book planned for July 1990 called "Remote Procedure Call Programming-Writing Networked Applications" by J. Corbin. ISBN 97247-1 (order by calling 1-800-SPRINGER). Does anybody have this book? Is it any good? What level of programmer is aimed at? And finally is J. Corbin on the net? I've got no connection to Springer-Verlag or Sun. My info comes from an ad on page 126 of the May/June 1990 SunTech Journal. I would like to know if others think this book is worth getting. Email to me and I'll summarize to the net. Joshua Levy (joshua@atherton.com)
corbin@nibroc.Eng.Sun.COM (John Corbin) (08/03/90)
In article <28186@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes: >Also, Springer-Verlag has a book planned for July 1990 called "Remote >Procedure Call Programming-Writing Networked Applications" by J. Corbin. >ISBN 97247-1 (order by calling 1-800-SPRINGER). Does anybody have >this book? Is it any good? What level of programmer is aimed at? >And finally is J. Corbin on the net? The book will not be out until November 1990. The title has been changed to "The Art of Writing Distributed Applications using Remote Procedure Calls". The ISBN is still the same. Of course I think that the book is good, but that is my biased opinion. The book is aimed at an experienced C programmer. You do not need prior networking experience or familarity with the UNIX operating system. It is a reference book with examples and should be useful to both new and experienced users of Sun's RPC Library. Here is the table of contents: Chapter Title 1 Introduction and Overview 2 eXternal Data Representation 3 RPC Protocol 4 RPC Programming 5 Low Level RPC Programming 6 Additional RPC Library Features 7 Rpcgen 8 Developing RPC-based Distributed Applications 9 Future Directions of RPC Programming Appendicies: 1 Sun RPC Information (getting program and authentication numbers) 2 XDR Specification 3 RPC: Protocol Specification 4 Differences Between the RPC Library on SunOS 4.0 and 4.1 I am on the net and any feedback on the book would be appreciated. John Corbin (jcorbin@Sun.COM)
jhc@m2jhc.uucp (James H. Coombs) (08/04/90)
In article <140113@sun.Eng.Sun.COM> corbin@sun.UUCP (John Corbin) writes: >In article <28186@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes: > >The book will not be out until November 1990. The title has been changed >to "The Art of Writing Distributed Applications using Remote Procedure Calls". >The ISBN is still the same. Of course I think that the book is good, but >that is my biased opinion. Do you discuss techniques for getting a server to fork() copies of itself, one per client? I have been looking through the RPC 4.0 distribution and am beginning to think that the RPC communications model has been implemented too strictly to permit the reasonable use of fork(). I can modify the code to implement an optional fork, but then I find that the server does not shut down when the client shuts down. I have no trouble implementing these requirements (e.g., keepalives) when working at the socket level. If you have a way to do this, I would like to hear about it. Also, if you have comments on the RPC communications model, that would be interesting. Perhaps you do this already, but it would useful to include a critique of RPC in your book: what is it good for and what is it not good for, how should it be improved? Thanks. --Jim
corbin@nibroc.Eng.Sun.COM (John Corbin) (08/08/90)
In article <46559@brunix.UUCP> jhc@iris.brown.edu (Jim Coombs writes: >Do you discuss techniques for getting a server to fork() copies of >itself, one per client? I have been looking through the RPC 4.0 >distribution and am beginning to think that the RPC communications >model has been implemented too strictly to permit the reasonable use of >fork(). I can modify the code to implement an optional fork, but then >I find that the server does not shut down when the client shuts down. >I have no trouble implementing these requirements (e.g., keepalives) >when working at the socket level. > >If you have a way to do this, I would like to hear about it. Also, if >you have comments on the RPC communications model, that would be >interesting. Perhaps you do this already, but it would useful to >include a critique of RPC in your book: what is it good for and what is >it not good for, how should it be improved? I have not implemented a service that forks copies as you described above and the book does not specifically discuss this subject. The book has a section on implementing your own svc_run() routine and why you might want to do it. Something I forgot to mention in my original posting is that the book is based upong the 4.0 release of the RPC Library and that I am a novice user of the socket based API. I typically use the RPC Library in its vanilla form when programming applications (for portability reasons). I don't beleive that the RPC model was implemented too tight to allow the reasonable use of fork(). I don't know if you have already thought of this, but if you want one server process per client, you could have the parent process register via the portmapper. When it gets a request from a client, it could spawn a child process that would bind to a different port number than the parent process. The child would not register itself with the portmapper. The child would attach itself to a port using the necessary socket calls and then pass the socket descriptor into the svcXXX_create() routine. The child would specify a zero for the protocol argument to the svc_register() routine to prevent the child service from being registered with the portmapper and thus unregistering the parent. The child would then return its portnumber to the parent process which in turn would return the portnumber to the client. The client would then have to bind to this portnumber (i.e. passing in a filled in sockaddr_in, including the port number, to the clntXXX_create() routine. From then on you should be able to use the vanilla RPC routines. One of the advantages of the RPC library is that it allows you to do your own binding if you don't want to take advantage of the portmapper. For those of you that don't want to mess around with the socket API, you could register the children using dynamic program numbers. A potential problem of having one server process per client is that you have now limited the number of clients that your service can handle (bounded by max processes per user). Another approach is to do dynamic load balancing on your server by spawning X processes to handle incoming requests. Where X is a dynamic variable dependent upon the incoming request rate (or some averaged value) and of course application specific information (weighting of remote procedures). I have not done a rigorous study on this so I can't give you hard numbers. Some potential problems with this approach is that the port can become the bottleneck (if using UDP) and you will have to modify the svc_run() routine. An alternative to forking is the use of light weight processes or threads. When 4.0 first came out, I looked at spawning light weight processes for every incoming request to a server. The problem with doing this under 4.0 was that certain system calls would still block the entire server (i.e. reading data from a disk file). Sun provided a special library of non-blocking system calls that could be used but then you had to modify your application to handle non-blocking system calls. This could be a problem if you are using a special purpose library for which you don't have the source for (ex: ISAM library). The fix for this is to make the LWP primitives available as true system calls. I am just getting into the issues of true multi-threaded servers and do not have any examples or insight to provide. John Corbin (jcorbin@Sun.COM) NFS Group Sun Microsystems (These are my opinions and should not be construed as coming from my employer)
jhc@m2jhc.uucp (James H. Coombs) (08/09/90)
In article <140323@sun.Eng.Sun.COM> corbin@sun.UUCP (John Corbin) writes: >I don't beleive that the RPC model was implemented too tight to allow >the reasonable use of fork(). I don't know if you have already thought of >this, but if you want one server process per client, you could have the >parent process register via the portmapper. When it gets a request from >a client, it could spawn a child process that would bind to a different >port number than the parent process. The child would not register itself >with the portmapper. The child would attach itself to a port using the >necessary socket calls and then pass the socket descriptor into the >svcXXX_create() routine..... This is interesting. From my perspective, however, I have not gained much by using RPC if I have to go do this much work at the socket level. In part, my evaluation is due to the fact that I frequently send lists through the network. RPC's ability to send and reconstruct lists is attractive in some ways, but I really need Inheritance C objects, not C structures. So I have to traverse the list, build a new list of objects, and free the memory from the original list. I don't really consider this a criticism of RPC, but it does limit its utility. It's just much simpler to read data from a socket into local variables, allocate an object, and then initialize the object with the data. If I have to deal with sockets anyway, then I may as well do the whole thing with sockets. I say this not to convince anyone of anything in particular, just to expose a line of reasoning that may be interesting to others. Happy to hear what I have forgotten, missed, etc. >An alternative to forking is the use of light weight processes or threads. This too is interesting. I am using c-tree. I do have the source code, but I cannot spend a lot of time making modifications. The other major problem with LWP is its (current?) lack of portability. Thanks for the discussion. --Jim