Path: utzoo!utgpu!cunews!bnrgate!brchh104!news From: news@brchh104.bnr.ca (news) Newsgroups: comp.sys.sun Subject: Re: rpc registration and how to tell of a cnode death ? Keywords: No Digest Subjects in Unmoderated Mode Message-ID: <3052@brchh104.bnr.ca> Date: 4 Jun 91 18:40:00 GMT Organization: Sunspots, Psuedo-Unmoderated Lines: 204 Approved: sun-spots@rice.edu X-Original-Date: Tue, 12 Jun 1990 22:51:05 GMT In article 1720009@hpbbi4.HP.COM Mark Lufkin writes: > In article 8606@rasp.eng.cam.ac.uk tim marsland writes: >> Yawn. Look, I've got nothing against HP/Apollo NCS, and I've heard that >> it has some technical improvements over SunRPC. Great - I have some >> tentative thought of my own about SunRPC failings. However, I've never >> heard the particular technical arguments in favour of NCS (despite asking >> HP in January), and *would* be grateful if someone would post a brief >> account of the differences, or points me at an HP document. Enquiring >> minds want to know. >> >> To be brutal, I get the feeling that your posting is simply OSF posturing. >> Fine, there are certainly people out there that like this sort of tosh >> -- but please don't post it out in the guise of a non-answer to some guy's >> question about a vaguely related problem. If you want to advertise >> NCS vs. SunRPC in this forum, *please* tell us why it's better. >> ``Because OSF says it is'' is not really good enough! Well, some time has passed since Mark's response to the request; I wanted to present another point of view. Disclaimer: I'm an engineer for Netwise, and my opinions may not be impartial. In any case, my opinions do not reflect any official position of Netwise. > OK, so I asked for that a bit. I promise I don't work for OSF though. > It was not OSF posturing but I would admit to NCS posturing - it is > my opinion though that NCS is better. > > The reasons why NCS was chosen over the Netwise/SUNrpc offering were: > There is a fuller description the following documents: > > Apollo NCA and SUN ONC: A Comparison (Nathaniel Mishkin) > > A Comparison of Commercial RPC Systems (Joshua Levy) > A response to the above by Nathaniel Mishkin > > I do not have any of these electrponically - if I find them I will > make them available - if anyone else has them, they could do the > same (the last two were in comp.misc some time back. At the time, Mishkin was an employee of Apollo. In June of 1989, Tony Andrews, a Netwise employee, posted "A Review of Current Product Offerings", which has various benchmarks of current Sun/Apollo/Netwise offerings (I believe this was to comp.protocols.tcp-ip). This would be an appropriate document to look at, along with the ones that Mark mentioned. I will re-post it if desired. > Just as a summary of why OSF chose NCS over SUNrpc/Netwise offering: Mark's reference appears to be the "OSF Distributed Computing Equipment Rationale", dated May 14, 1990, from the Open Software Foundation. OSF is specifying an entire Distributed Computing environment--Naming, Security, Threads, as well as RPC. OSF chose NCS 2.0: "...a joint submission of Digital and Hewlett-Packard." This is not a shippable product. It is not appropriate to compare an unavailable NCS 2.0 against Sun's RPCGen. Sun has announced availability of the Netwise RPC Tool in the Second Half of 1990 ("Distributed Computing Road Map--An Outlook on the Future of Open Network Computing" Sun Microsystems, Inc., dated April 30, 1990). A comparison of NCS 2.0 and these new Sun offerings would be appropriate. Based on Mark's highlights from the OSF document: > - minimal programming complexity - NCS adheres more closely to > the local procedure model making it easier to use. I'm not sure what this is a reference to. Both NCS 1.x and the current Netwise RPC Tool have been generating C code for client and server stubs. These stubs handle packing and unpacking the data and networking operations, making an RPC call appear as if it's a local subroutine call. Both will continue to use stub generation in future versions. Besides the joint Netwise/Sun submission to OSF, Sun submitted RPCGen separately. Perhaps the OSF is talking about the non-transparency of RPCGen. I would be interested in seeing some clarification of what OSF is talking about--it's not clear from their Rationale. > - the RPC protocol is clearly defined and not subject to change by > the user (Netwise RPCTool IDL compiler). The OSF rationale is referring to Netwise's customization feature. Both the server and client sides of an RPC call are modeled as a state machines. A user can add hooks to modify what happens in a particular state or change the state transitions. There are 2 implications in the OSF document. The first is that customization of the RPC specification is not valuable. Netwise's expericnce has been that customization is important to our customers. The second implication is that customization creates possible interoperability problems. Since this is a technical forum, an appropriate way to explain Netwise's philosophy is to provide a real example of customization. I'll apologize in advance for glossing over some of the details, but hopefully the general point will be clear: One of our customers wanted to have a multi-tasking server (i.e., a server that can handle requests from multiple clients simultaneously). Multi-tasking servers are quite straightforward in a UNIX environment--Netwise provides "canned" code to provide a multitasking server for UNIX systems. Unfortunately, our customer's OS does not support the concept of copying network file descriptors on a fork() call. Saying the problem another way, the OS's fork() mechanism does not permit multiple processes to use the same address for connections. Netwise created customization so that a client's first RPC call would instead perform two RPC calls. The first call is to the named server, which returns the (unnamed) address of a worker to the client. The second call is from the client to the worker which establishes a connection for subsequent RPC calls. From the point of view of the applications programmer, a single RPC call has been performed. The customization, which is declared in the RPC Specification File, provides a means of containment for the custom functionality of the call. The application *could* have made a separate RPC call to get the address of the worker, but that doesn't permit the applications programmer to maintain the abstraction of the RPC call. If our customer moves his server to a UNIX environment, he can simply remove the customization, re-compile, and run with no modification to the application code. An RPC Toolkit could include some "standard" set of customization features, but which ones would you include? Customizations could include modifications to security, naming, auditing, asynchronous RPC calls, etc. Which do you include with the Toolkit? Netwise felt the only sane way to proceed was with having the users add whatever they want -- an "Open Architecture" approach. Finally, it's not clear what an "RPC protocol" is or what it would mean to change one. My feeling is that the RPC Specification File is specifying the protocol for some set of RPC calls. The customization is part of that Specification File. Sure, you could create a buggy customization. In Toolkits where RPC customization wasn't available, you could have bugs in the application code performing the customization. Bugs are bugs. Again, the difference is that Netwise contains the customization in one centralized location, providing a layer of abstraction for the applications programmer. This may well wind up being a *religious issue* about RPC technology. > - uniform transport behaviour. NCS does not depend on transport > characteristics. An example - if UDP is chosen as the underlying > protocol limits are imposed on the size and number of arguments > as well as the reliebility. NCS allows the choice of a variety of > transports without affecting the operation. The Apollo NCS 1.x uses datagram-oriented transports. Unfortunately, RPC needs to be built on top of a reliable transport. Apollo built their own protocol on top of datagram transports to achieve reliability. In some (all?) systems, these are not implemented in the kernel. It's unclear why a home-brew reliable transport would be superior to using the reliable transport provided by the OS. It could be slightly faster in some environments, particularly if few packets are lost. Tuning in more hostile environments would probably be difficult, particularly since the application may not have access to the appropriate real-time tools that kernel code does. Finally, there is the added code space for implemting the reliable transport on top of the datagram transport. In the NCS2.0 product, my understanding is that they will use both connection-oriented and datagram-oriented transports (Mike?). The next-generation Netwise tool will be offering datagram transports. However, we will be offering the raw datagram functionality to the application--message delivery will be unreliable and message size will be limited to the size permitted by the transport. This is what OSF means when they say we don't have uniform transport behavior. Why did we make this choice? Basiclly, we feel that a connection-oriented transport is the way to go. However, if an applications writer is willing to deal with the reliability and space constraints, then a raw datagram transport interface can be used. Assuming appropriate reliability characteristics for the datagram transport, we will have much lower overhead per packet than either flavour of NCS2.0. Finally, a datagram transport is necessary to support broadcast. NCS2.0 will run on top of either a datagram or a connection-oriented transport, but you're really getting a connection-oriented service in either case. Mike: what will NCS2.0 do WRT broadcast? Will it be available with both types of transport? If broadcast is not available under connection-oriented transports, won't this constitute non-uniform transport behavior? If a Netwise user really wanted unlimited data under datagrams, he could add it with customization :-). > - allows integration with a threading package, also integrated with > authentication s/w (Kerberos). Also allows a 'pipe' capability for > bulk transfer of data. The Netwise tool has customization that would give the analogue to 'pipe'. The callback customization would allow a server to throttle data coming from the client. Sun's RPC currently does not have multithread support; they have announced multithread support in the Second Half of 1991. They will have Kerberos in the first half of 1991 (see document reference above). Netwise's current products support multithreaded applications (with the restriction that each connection be accessed within a single thread). What does NCS2.0 do in environments that don't support multiple threads?