This page defines selected NFS and related terminology. If there are any NFS-related terms you'd like informally defined that aren't already here, please email firstname.lastname@example.org.
NDIS is one of the three popular standard interfaces to networking cards under DOS/Windows (see also ODI and Pktdrvr). It is the foundation of most networking products from Microsoft, and many other vendors. If an Ethernet card has an NDIS driver, any protocol stack which wishes to interface with the network cards can support all cards with NDIS drivers by simply writing for one interface standard, instead of needing to know the proprietary interfaces to each make and model of Ethernet card. Tsoft includes the DISPKTMX.DOS 'shim', a modified version of DISPKT9.DOS, which provides a Pktdrvr interface on top of an NDIS driver, thus letting our WatTCP NFS Client run. This driver is also capable of IP multiplexing so that two TCP/IP stacks can run over one Ethernet card at the same time, so most any NDIS TCP/IP stack can coexist with the WatTCP client. NDIS version 2 is real-mode/MS-DOS based NDIS. NDIS 3 is protected mode/32-bit NDIS which was introduced in Windows for Workgroups.
NFS is the Network File System Protocol, a standard protocol for sharing files between computers over a network originally developed by Sun Microsystems. The latest version of the NFS protocol is version 3, though most of the world is still operating on the version 2 protocol, the most widespread (version 3 was introduced in early 1995 and raises some of the limits of the version 2 protocol, as well as provides some new RPCs (see RPC) to make the protocol more efficient. The NFS protocol version 2 is the protocol currently implemented in Tsoft's NFS Clients for DOS/Windows and our Win95 client. We'll be adding version 3 support to our Win95 client. The NFS protocol is stateless at the server.
Mounting is the process of attaching a remote file system onto the local file system. In the case of Tsoft's NFS Client for DOS/Windows, the remote file system is assigned a DOS drive letter. For Tsoft's Win95 client, several remote file systems may be mounted in a hierarchy on a single local drive letter. The Mount process involves communicating with the server to get the 'root file handle' for the file system, which can later be passed to the lookup RPC to locate other file handles in the remote file system directory hierarchy. After the root file handle is obtained, the client sets up local data structures and makes the new file system known to DOS or Windows. There are more details involved in the mount process, such as authenticating the user and possibly communicating with remote locking services to setup file sharing and record locking.
ODI is one of the three popular standard interfaces to networking cards under DOS/Windows (see also Pktdrvr and NDIS). It is the foundation of most networking products from Novell, and other vendors. If an Ethernet card has an ODI driver, any protocol stack which wishes to interface with the network cards can support all cards with ODI drivers by simply writing for one interface standard, instead of needing to know the proprietary interfaces to each make and model of Ethernet card. For use with Tsoft's NFS Client for WatTCP, a 'shim' driver called odipkt is also handy to use; it provides a Pktdrvr interface on top of an ODI driver and allows the WatTCP NFS Client to operate.
The Pktdrvr standard is one of the three popular standard interfaces to networking cards under DOS/Windows (see also NDIS and ODI). It is the foundation of most networking products from FTP Software, the company which developed the specification, and many other vendors. If an Ethernet card has a Pktdrvr driver, any protocol stack which wishes to interface with the network cards can support all cards with Pktdrvr drivers by simply writing for one interface standard, instead of needing to know the proprietary interfaces to each make and model of Ethernet card. Tsoft's NFS Client for WatTCP runs over a Pktdrvr interface natively, and provides a packet multiplexor so that other Pktdrvr based TCP/IP stacks can run simulataneously, such as Trumpet Winsock.
RPC is the Remote Procedure Call Protocol, a protocol also developed by Sun Microsystems. RPC is an abstraction of the network layer, that makes it easier for programmers to call services on remote machines. NFS is specified using a set of RPCs or essentially 'primitive functions'. The NFS client combines a series of Remote Procedure calls in a manner to produce the effect the client operating system expects for its file system. An example of an RPC is the lookup() call, which looks up a file in a directory; the client walks a full pathname using a series of lookup() calls in deeper and deeper directories. From the programmer's perspective, invoking an RPC is almost as simple as calling a local function, except that there is the possibility the RPC won't complete validly if there is a network failure so the client code must check for this possibility. The RPCs which make up a higher-level protocol like NFS are specified in a simple specification file and then utilities in the RPC system generate all the networking code for the programmer and combined with a stock RPC library is all she needs to invoke remote procedures.
A shim is a TSR or driver which converts from one interface to another. Examples are ODI Pkt which provides a Pktdrvr standard interface on top of an ODI driver, and DISPKT9 which provides a Pktdrvr interface on top of an NDIS driver.
The NFS protocol is stateless, in that the server doesn't remember which clients have particular file systems mounted or which files are open. Actually this isn't totally true since the server's mountd typically remembers which file systems are mounted, but it's knowledge is only for administrator's and other's information and is not actually necessary for the operation of the NFS protocol. In order for the server to not need to remember which files are open, the NFS file handle is 32 bytes long and contains enough information for the server to uniquely identify the local file (information such as file system device and inode number). Statelessness has the nice effect that clients can often survive server reboots or crashes and don't need to re-mount the file system.
A TCP/IP Stack is software which extends the operating system to provide TCP/IP services to applications. They are typically implemented as TSRs under DOS and Windows, or Windows VxDs or .DLLs. Tsoft's NFS Client is available for several TCP/IP stacks, including WatTCP (a TCP/IP stack compiled into the NFS application), Novell's TCP stack, Microsoft LAN Manager TCP/IP, Trumpet TCPDRV, and now as a VxD client for Microsoft TCP/IP under Windows 95 and Windows for Workgroups.
A TSR, or Terminate and Stay Resident program, is a piece of software which loads into memory in the background and typically either extends the services provided by the operating system (DOS), or provides services which can be popped-up via hotkeys by the user. With Tsoft's NFS Clients, TSRs are typically used for two purposes, though VxDs are also used with our new Windows 95/WfWg client. The first purpose is for the TCP/IP services, and the second is for the NFS client which makes use of the TCP/IP services. Tsoft's WatTCP client combines these into a single TSR. A TSR is often loaded in the autoexec.bat file or config.sys.
Unmounting is the reverse process from mounting. The client removes the remote file system from DOS' or Windows' knowledge, and tells the NFS server that it no longer is using the file system. Before allowing an unmount, the client may ensure that there are no locally open files on the file system, ie. that the file system is not busy.
One of the problems with TCP/IP stacks under DOS is that there is really no standard for interfacing to them, so the programmer of a particular application is forced to do extra programming to interface with multiple stacks. The Winsock standard is an attempt to rectify this situation for TCP/IP applications running under Windows; Winsock is a standard interface to the TCP/IP stack, so a programmer can write her application to use the Winsock specification and it will work (in theory) with any TCP/IP stack which implements a Winsock interface. Nearly all TCP/IP stacks designed for Windows now implement Winsock, including stacks from Trumpet International, Microsoft, Beame and Whiteside, FTP Software, HP, 3Com, NetManage, Distinct, and more. Tsoft's NFS Client is available for or with (at low cost) Novell's Winsock TCP/IP stack, an excellent way to get Winsock support along with our NFS client.
A VxD, or Virtual Device, is a 32-bit Windows device driver. It has the nice property of not using any (or very minimal amounts) of memory below 1 Megabyte, freeing it up for use in DOS-boxes. Tsoft has a Windows 95 and Windows for Workgroups NFS Client in public beta test which is implemented as a VxD.
Copyright 1996, Tsoft. All Rights Reserved.