Xref: utzoo comp.protocols.tcp-ip:2320 comp.lang.c:6886 Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!apollo!mishkin From: mishkin@apollo.uucp (Nathaniel Mishkin) Newsgroups: comp.protocols.tcp-ip,comp.lang.c Subject: Re: C binding interfaces for TCP/IP Message-ID: <39f8b524.c366@apollo.uucp> Date: 29 Jan 88 22:38:00 GMT References: <25@vdelta.UUCP> <2168@cognos.UUCP> <3256@psuvax1.psu.edu> Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Lines: 119 In article <3256@psuvax1.psu.edu> schwartz@gondor.cs.psu.edu (Scott E. Schwartz) writes: >In article <2168@cognos.UUCP> jimp@cognos.UUCP (Jim Patterson) writes: >>In article <25@vdelta.UUCP> dave@vdelta.UUCP (Dave Arnold) writes: >>>Are there efforts underway to standardize a C language interface for TCP/IP? >> >>Sun has developed a definition called RPC (Remote Procedure Call) >>which is becoming a defacto standard in some environments. > >>Sun has published the protocol to encourage its >>implementation on other systems. > >By the way, Apollo recently announced some other RPC protocol that >they would like to become the standard, but I don't know anything >about it. Apollo's RPC system is called the Network Computing Architecture (NCA). Apollo's portable implementation of NCA is called the Network Computing System (NCS). NCS runs on a BSD and System V Unix variants, VMS, and MS/DOS. NCA defines a special-purpose lightweight request/response protocol that can (and does) run over a variety of datagram (unreliable) services (e.g. UDP/IP), yet maintains the "at-most-once" call semantic. (Calls to procedures declared to be idempotent are supported at slightly lower cost.) The protocol supports reflecting server exceptions back to clients and asynchronous interrupts (quits) at the client being passed to a server process running on the client's behalf. Fragmentation and reassembly are performed if the input or output parameters don't fit in a single datagram. The reason we went with a special-purpose protocol was to minimize message exchange overhead and load on server and client. (We expect it to not be uncommon for a single server to be contacted by 100s of clients over, say, a one minute period. We expect it to not be uncommon for a single client to want to contact 100 servers over a similar period.) Also, not all virtual circuit protocols are created equally, making it hard to write a single package that will run equally well over a variety of them. NCA defines a data presentation protocol, the Network Data Representation (NDR), which operates in what we call a "quasi receiver makes it right" fashion. I.e. it supports a fairly rich set of different canonical scalar data representations which a sender can chose from and a receiver must convert from (if necessary) upon receiving the data. Our goal is that when like machines communicate, no data conversion need occur. NCA defines a language, the Network Interface Definition Language (NIDL), that looks like (say) a Modula-2 interface. (The language also has a C-like variant, which tries to be in the spirit of ANSI C and C++.) NCS includes a compiler for NIDL. The compiler produces client and server stubs that interface with the network runtime and handle data conversion issues. The NIDL compiler can be used in conjunction with applications written in Unix "f77" (no small task, I'm afraid), as well as C. The NIDL compiler and NCS runtime go to fairly great pains to avoid data copying and calls to dynamic storage allocation routines. NIDL has a mechanism for dealing with types not marshallable by the compiler (e.g. arbitrary data structures like trees, linked lists). For each such type, the interface defines a corresponding "transmissible type"; the interface writer is obliged to write routines (called from the automatically generated stubs) that convert between the transmissible and the abstract type. This scheme has the virtue of being declarative as far as the interface is concerned -- the interface (and not any user-written code) precisely specifies what appears "on the wire". NCA defines and NCS supports a rich, object-oriented binding model promoting a view of distributed computing that is based on what you want to do, not where you want it done. (I know that was buzzspeak, but I don't want this to go on forever.) This model is embedded in NIDL, making it possible to define interfaces and write applications that have no outward sign of being "remote" or having anything to do with networks, host names, or network addresses. Various Apollo projects and products have been implemented using NCS. These include a replicated object (service) location service, a replicated user registry (upon which the Unix "getpw" calls are implemented), a distributed software license checkout system (Network License Server). Outside Apollo, various projects based on NCS are underway, some at companies and some at universities. University of Iowa developed a simulation system that uses a Alliant FX series minisuper and an Apollo cooperatively. An independent implementation of the NCA/RPC protocol was done at the San Diego Supercomputer Center for their CTSS/Cray system. Since someone referred to Sun RPC as a "de facto standard", I feel free to introduce my (admitedly biased) comment that (a) I don't really see this as being the case, and (b) NCA/NCS has numerous technical advantages over Sun RPC. Sun RPC is widespread because NFS is based on it. Until recently, there wasn't an effective interface definition language or compiler for that language (and the current one has various limitations), thus making Sun RPC not a terribly attractive system for developing a variety of large distributed applications. Correct (i.e. at-most-once) call semantics require the programmer to know to choose (and to in fact choose) a proper (i.e. reliable, virtual circuit) underlying transport (e.g. TCP/IP). Use of UDP/IP even in the case of idempotent procedures can cause program failures if at runtime it turns out that the input or output parameters don't fit into a single UDP datagram. The Sun RPC interface definition language (RPCL) obliges all procedures to take one input parameter and return results via function value (essentially burdening the application program with the marshalling and unmarshalling process). Now I know there's someone who knows (and is going to tell me and the world) that you can get Sun RPC from Sun (or whoever) for free, and Apollo is not giving away NCS. We do have a draft specification of NCA which we will give away. (Who knows, we may have to charge the cost of materials and mailing if we get a ton of requests for it.) The NCS source code costs money. This is not the appropriate forum to go into details about cost and value, but I will at least say that universities can (under license) get it for a nominal amount of money. We hope that binary versions of NCS will become readily available at low price. The world will have to decide whether it wants to pay for it. We think it's worth it. There was a paper describing all this in the Summer 1987 Usenix. People can feel free to contact me for more information. -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {decvax,mit-eddie,umix}!apollo!mishkin