Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!ucbvax!bloom-beacon!pae From: pae@athena.mit.edu (Philip Earnhardt) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Message-ID: <1990Jul20.034330.8152@athena.mit.edu> Date: 20 Jul 90 03:43:30 GMT Sender: Phil Earnhardt (onecom!wldrdg!pae) Organization: Netwise, Inc. Lines: 151 In <4b872c9b.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: >> 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 :-) (I'm amused by the reason :-). It may be helpful, though, to consider a real, live RFC--comments you get from a Request for Comments may give you some hints on how to make NCS work efficiently on the Internet. One thing I found ambiguous in the Architecture book was the use of Fragment Acknowledgment. Page 30 of the Architecure book says that the fragment acknowledgment may be set in a packet to request acknowledgments of the individual fragments. However, I found no mention of how a programmer would require or prohibit fragment acknowledgment. Under what conditions would someone want fragment acknowledgment? Why is this something an applications developer should worry about? On page 43, the "Suggested Time" for fragment acknowledgment is 1 second (it's my understanding that all of these timers are hardwired in a given NCS implementation). Isn't a 1-second timeout far too short for fragment acknowledgment? If the mean round-trip time for 2 Internet hosts is 5 seconds, won't this mean that fragments will get needless multiple retransmissions? >> 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. I'm talking about NCS's connection-oriented protocol on top of UDP. If you truly think that you've invented a better mousetrap, these are the folks that I'll believe. Speaking of TCP/IP, from an earlier posting: |> A couple of general questions: |> |> 1. Why is NCS2.0 being offered on top of connection-oriented transports? |> Under what conditions will you recommend that programmers specify using |> connection-oriented transports? > Some environments have only COTPs. (E.g., our ISO/OSI friends have not > yet seen the wisdom of making a priority defining and implementing CLTPs.) > We want NCS to run in these environments. Hence we must make NCS run > over COTPs. It is true that some environments only have COTPs. However, I have never seen a TCP/IP environment that did not have access to UDP/IP and vice versa. (Does anyone know of any exceptions?) Why bother putting NCS2.0 on top of TCP/IP? If you do provide NCS on top of TCP/IP, when do you recommend that it be used? >> 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. Either multi-threading is a keystone of NCS, or it isn't. If multithreading isn't available in all environments, then your proposed mechanism of doing asynchronrous RPC via forking a thread won't work. > 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.) How portable is it? How does the availability of NCS compare with RPCGEN? How about Netwise's RPC Tool? How big is the NCS compared with these other products? > 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.) I believe you mean that NCS provides no control of the granularity. One can control the range of a broadcast by changing the address mask. >> 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? If you're doing asynchronous calls, you have some point when you have enough information to perform the call, but don't need the result immediately. A simple strategy is to go back to what you're doing until you need the results, then block waiting for them. If you don't understand that, then I don't understand what you meant in an earlier posting: > My religion says that they're a bad idea because they're hard to understand, > represent an unnecessary new aspect in the computing model, and that one > should use existing primitives for asynchrony (process) and communications > (procedure call) together to achieve the same effect. Do you mean that a process should fork a new thread to do the RPC call? In your example, isn't the parent thread going to do stuff for "a while" then "check for a result" of its child? Sounds at least as hard to me. For other readers: it's useful to remember one other thing about async operations. Async is pretty simple to understand if there is only one outstanding operation. It is possible to have multiple async calls over a connection, but the rules get much more complicated. I would not recommend multiple outstanding asynchronous calls over the same connection. > 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)? Yeah, it looks like multi-threaded systems will become more widespread. It will be interesting to see what sort of problems that this unleashes on the world. I'm not tremendously enthusiastic about locking out all other threads every time I want to modify a global. The one that really frightens me, though, is the process of software maintenance. Some junior programmer will not understand THE RULES for changing a multi-threaded application and will introduce bugs that will not surface for months later.... I had claimed that there was no automatic system for detection of data access collisions; this was incorrect. It turns out that the Space Shuttle computers are multiprocessing but not memory-mapped--different processes are accessing the same global data. Unfortunately, the computers provided facilities for protecting only 256 variables; a typical shuttle mission has over 9,000 shared variables. The computer designers came up with a novel solution: since are points of synchronization between the processes, the relative time that each process is accessing each variable is known. From this data, the designers were able to create an "alabi file" for each variable that exhaustively examined each access and *proved* that no reads and writes overlapped. Needless to say, computation of these proofs take a rather astonishing number of computrons and had a rather negative impact on code flexibility in the shuttle. Phil Earnhardt Netwise, Inc. 2477 55th St. Boulder, CO 80301 Phone:303-442-8280 UUCP: onecom!wldrdg!pae My opinions do not reflect any official position of Netwise.