Path: utzoo!attcan!uunet!decwrl!elroy.jpl.nasa.gov!sdd.hp.com!apollo!mishkin From: mishkin@apollo.HP.COM (Nathaniel Mishkin) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Message-ID: <4b872c9b.20b6d@apollo.HP.COM> Date: 11 Jul 90 15:04:00 GMT References: <404@bischeops.UUCP> <4b423481.20b6d@apollo.HP.COM> <1990Jul5.040529.16093@athena.mit.edu> <1990Jul10.224543.20314@athena.mit.edu> Sender: root@apollo.HP.COM Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 159 In <1990Jul10.224543.20314@athena.mit.edu> pae@athena.mit.edu (Philip Earnhardt) writes: >Actually, things should work pretty smoothly under TCP. Since the connection >is being maintained by the kernel, the acknowledgment can be sent immediately >after the packet is processed by the kernel. NCS would have the ack sent out 3 >seconds after the user process has processed the data. Also, acknowledgments >can be sent back to the server for fragments of the message. I suspect things WON'T work smoothly under TCP, for the reasons I said. First, your scenario (100 different clients each make a single non-idem call to a server) implies that the server is able to open (and keep open without being considered anti-social) 100 TCP connections. (BTW, whether your system lets you have more than 32 file descriptors is only the first issue. How many simultaneous TCP connections your kernel allows and how much these "cost" in kernel resources are others.) Second, with TCP, any data sent on a connection that is not yet ack'd is consuming wired kernel buffers. There is nothing that REQUIRES a receiving TCP to acknowledge a TCP segment immediately upon its receipt. TCP implementations should (lord knows if most do) have the goal of piggy-backing ack's on data flow in the reverse direction to avoid the sending of gratuitous empty TCP segments (IP packets) that simply contain ack info. In any case, TCP having the "connection maintained by the kernel" really has pretty little to do with anything. NCS could ack every response packet immediately after it arrived (as opposed to postponing the way it actually does). The delay induced by switching out from the kernel to user mode upon packet receipt isn't the problem. The problem is that the sender is stuck with whatever ack policy the receiver is following. Sure, you can solve the sender's problem by ack'ing all the time. However, if you know the sender has a moderate to large amount of buffering capabilities (because the buffers are page-able and in user space), you can ack at a more reasonable rate and save network bandwidth. >It's probably not necessary to understand all the nuances of the NCS >implementation in order to understand the fundamental problem with a >connection-oriented protocol implemented outside the kernel on top of a >datagram transport. There is certainly some reason to be concerned that it might be the case that the kernels we have around don't provide enough information in a timely fashion to user mode to make the implementing of a connection oriented protocol (like NCS over UDP is) as good as one would like. Our (and other's) experience has shown that one can live with the limitations. (And as you can see from my earlier comments, the alternate approach of using TCP is not without limitations either.) >If the connection-oriented scheme at the user level were the way to go, why >isn't everyone else jumping on the bandwagon? Beats me. OSF seems interested. >Why not implement X that way? Ask the X folks. Presumably they decided that they were more interested in doing window system stuff than network protocols. >Are there any RFCs that discuss the NCS technology? At the time we set out to write the NCA book, we considered whether it could/should be an RFC. For better or worse, the book was written with a WYSIWIG editor and (at least until recently) RFC's had to be in flat ASCII form. Apparently Postscript RFCs are now accepted. We could produce the book in Postscript and submit it as an RFC. Somehow I think it's probably simply for people who are interested to just get the book. (The royalties to HP are nothing to write home about, I assure you :-) >Have any of the Internet gurus endorsed it? As I understand it, the topic of RPC is one that surfaces regularly at some IETF working group meetings. I don't think they've endorsed anything at this time. > >> Everything is a matter of degree. Broadcast is a feature that a relatively >> few (and hopefully almost no) applications need. > ^^^^^^^^^ >??? In order for your GLB to work, you need broadcast. OK, substitute "close to one" for "almost no". The idea is that most applications will leverage off of a single broadcast (to the GLB) so that those applications themselves don't have to use broadcast for anything else. Also, the GLB can be be accessed without broadcast (i.e., via specifying its location in a local config file). >> See "Network Computing Architecture" (Prentice-Hall, ISBN 0-13-611674-4). >> Let me know if it doesn't answer all your questions. We tried to be >> complete, but I wouldn't be surprised if we failed in some areas. There's >> always the next edition :-) > >I had already looked through this book. I hadn't found answers to the >specific questions I had asked: > > o What type of packets NCS is sending (UDP or IP). UDP. I had intended there to be an appendix to the book titled "NCA/RPC in the IP environment". It fell through the cracks. The mapping is straigtforward. One NCA/RPC datagram is one UDP packet. > o When acknowledgments are sent. (there's some information about the timers, > but there's no timeline charts about what goes down the wire.) Sounds like a good area for improvement. Presumably you understand the picture based on my postings. > o How retransmission timers work--when are they used, what values are > they set to, how the application can change the values. Actually, I thought this was covered, but perhaps not clearly enough. >For these systems, there will have to be modifications to the OS to support >multiple threads (I assume non-preemptive application-provided multithreading >won't work). There's the added expense of a new OS and the hassles of >configuring/installing the system software. Well it's a surprise to me that the OS needs to be modified. A number of people have written useful multi-threading packages that don't require OS mods. Presumably some OS's would require mods. Presumably some OS's don't have C compilers either. My goal is not for me to fix every problem in the world. >Some of these computer systems may be at the end of their product cycle; the >manufacturer may be unwilling to make any changes to their OS. There may be >architectural reasons that mutlithreading can not be implemented in some >environments. Should Distributed Computing not be available in these >environments just because NCS implementations require multiple threads? Clearly someone should figure out how to build implementations that don't require multiple threads. Like I said, my goals is not for me to fix every problem in the world. The portability of a single implementation of a system is only one measure of a system's usefulness. NCS is highly portable. No, it is not infinitely portable. Sue me. (Be prepared to sue lots of people who produce lots of software that lots of people use and consider to be portable.) >The response didn't seem to address the issue raised. How exactly does one >specify the granularity of the broadcast? Sorry. I didn't understand this to be your question. There is no control over the granularity (by which I assume you mean "scope"). This is one of the reasons people dislike broadcast. (Some people, including me, like MULTIcast, but unfortunately, access to such facilities is pretty hit-or-miss these days.) >The comparison between (preemptive) multiple threads and asynchronous calls is >interesting. I find asynchronous calls fairly straightforward--you place the >call, do something else for a while, check for a result, and get the reply. Another religious issue for sure. My problem is that I don't know what "a while" and "check for a result" mean: when and how do I do it? Multi-threading systems will be implemented and become widespread. Such systems have primitives for doing synchronization (signalling and waiting for events). Why do you want to invent and make me use duplicate primitves (in support of async RPC)? -- Nat Mishkin Cooperative Object Computing Operation Hewlett-Packard Company mishkin@apollo.hp.com