Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!NRTC-GREMLIN.ARPA!mrose From: mrose@NRTC-GREMLIN.ARPA (Marshall Rose) Newsgroups: mod.protocols.tcp-ip Subject: Re: NFS comments Message-ID: <3365.535572105@nrtc-gremlin.arpa> Date: Sun, 21-Dec-86 18:42:01 EST Article-I.D.: nrtc-gre.3365.535572105 Posted: Sun Dec 21 18:42:01 1986 Date-Received: Sun, 21-Dec-86 21:37:02 EST References: <8612210243.AA26846@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 68 Approved: tcp-ip@sri-nic.arpa Well let me try to answer that. I've only read the spec twice and don't have it here in from of me but here goes... FTAM is based on the notion of a "virtual filestore" (sound familiar, huh?) The filestore consists of zero or more files, each with an unambiguous name. Each file has a set of attributes (of which filename is one) and some contents. The attributes have the usual permission stuff along with a description of the kind of information the file contains (e.g., iso646 ascii, octets, bits), and a description of the access discipline (my term) for the file. The contents is a binary tree. Each node in the tree contains - node attributes: node name length of arc back to parent a flag saying whether data is attached to this node - attached data (if any) - a list of children Now, there are a couple of ways that you can implement a UNIX-style regular file. The simplest is to have just the root node with the entire file contents as the attached data (as an octet string) and no children. In this case, the access discipline is rather inconsequential, since you can only get at one data element at a time and there is only one to choose from. Alternately, for a file like /etc/passwd, you might have a root node with no data, and a child for each line in the file. The access discipline would allow you to specify any child element you want when you wanted to read or write. There are in the spec, several document types and access disciplines listed with pre-defined meanings. Others can be chosen via "bi-lateral" agreement. In the NBS OSI Implementor's Workshop Agreements, they have defined a new document type called "directory" in which the nodes are, you guessed it, file names. Assuming you had an FTAM server which supported that document type, an FTAM client could do the DIR and NLST commands that we've all become so attached to. So to answer your question: FTAM imposes on everyone the same fairly general file model. Each FTAM server consists of a protocol engine for FTAM and a localFS-virtualFS engine. For UNIX-like systems, going between the two is rather restricted unless you want to put a lot of smarts in your code (at which true UNIX-ites would gasp, I'm sure people are reeling at my /etc/passwd example!). In this case, the question of "is it ascii or is it octet-aligned or is it bit-aligned" is something the localFS-virtualFS engine for UNIX would have to answer. Now of course, if you had something like DEC's RMS in your filesystem, FTAM makes more sense as there is a closer match between the local and virtual filestores. It is important in all of this however, to remember what OSI is: a method for tying together dissimilar systems. This is done by choosing a sufficiently general model which is (hopefully) a superset of all existing systems, and then letting people code local2virtual engines at the network boundary. With respect to RPC, there are such notions in OSI. My favorite is called ROS (Remote Operations Service) which is a fairly simple invoke-result, invoke-error protocol with provisions to support "once-only" execution of operations. FTAM is not meant as a competitor to ROS (and quite frankly, had *I* designed FTAM, I would have put FTAM on top of ROS), but is trying to solve a different problem, which perhaps has overlap for certain applications. /mtr