Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!ucsd!ucbvax!bloom-beacon!pae From: pae@athena.mit.edu (Philip Earnhardt) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Message-ID: <1990Jul10.225103.20551@athena.mit.edu> Date: 10 Jul 90 22:51:03 GMT References: <1990Jul5.041344.16511@athena.mit.edu> <1990Jul5.042028.16788@athena.mit.edu> <4b69c9e1.20b6d@apollo.HP.COM> Sender: onecom!wldrdg!jake Organization: L & E Technologies, Inc. Lines: 70 In <4b69c9e1.20b6d@apollo.HP.COM>, mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: > I understand your position and I don't know that there's much point > arguing about the relative merits of customization. We simply disagree. This seems to be a bit of a 'back-off' from your previous postings ... are we calling it a draw (i.e. yes there are dangers in customization and yes there are instances where they are neccesary)? > Async RPC is another one of those religious issues. 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. And in anticipation > of the "but not all systems support cheap multi-threading" objection, > I'll say (a) let's fix that and not introduce new features, and (b) it > can't be that much harder to bring up a simple threading package than ^^^^^^^^^^^ well in the RPC Tool case, it is infinitely harder as no modifications to the base system were neccesary to support asynchronous RPCs. The customizations that you find so objectionable make it fairly trivial to support asynchronous RPCs. > it is to bring up the async part of an RPC system that support async > RPC and the return is much higher for doing the former than the latter. I think that it is only hard to allow asynchronous calls when the RPC system does not allow customization of its state transitions. The RPC Tool needed no specific modifications to allow asynchronous RPCs, just some customizations to the RPC spec to modify the state transitions. This allows the customer to decide which method of asynchrony is best for their application. If asynchronous RPCs are 'bad', why expend the effort to add cheap multi-threading to operating systems that don't currently support it? Also, multi-threading support may or may not be easy to add to an existing system and it is certainly not easy for application developers to add into existing applications. For this reason, it seems to me that offering asynchronous RPC within the framework of the existing RPC system (and allowing multi-threading or multi- tasking in environments that support it) is a must. In the Network Computing Architectures book, embedded microprocessors are specifically mentioned (page 18 if memory serves) ... are you suggesting that multi-threading be added to these systems? > Authentication and privacy features are part of NCS 2.0. Maybe I am misunderstanding here, but it sounds like you are saying that NCS 2.0 will provide methods for authentication and for privacy that are 'hardcoded' into the system. If (for some reason) a customer has their own method that they wish to use (i.e. their own encryption scheme) they will not be able to use it and that instead they must use the method provided by NCS 2.0 ... am I jumping to conclusions? BTW, in some hallway discussions that we have had around here, the concept of uniform transport behavior (sp?) has come up and it leaves me a bit puzzled. From my (perhaps somewhat limited) understanding of the current thinking in the networking community, there appear to be two camps, connection-oriented and connection-less (thus the CO/CL split in the OSI) and what uniform transport behavior in effect does is to come down clearly in the CO camp. (i.e. whether the transport is CO or CL is unimportant (except in the case of broadcast) as NCS establishes a CO protocol in either case). Is this the intent? The Netwise approach is to have uniform CO transport behavior and uniform CL transport behavior and to therefore recognize this fundamental split ... I am curious as to your thinking on this. ------------------------------------------------------------------------------ The verbiage above does not neccesarily reflect the views of my employer or client (Netwise). jake edge - L & E Technologies, Inc. 2888 Bluff St. Suite 142 Boulder, CO 80302 Ma Bell: (303) 440-1142 UUCP: ...!onecom!wldrdg!jake