INFLUENCE OF FEATURES ON DESIGN AND ARCHITECTURE                           Back To Home

Using a Client/Server Architecture:                                                          

Click here to get an overview of the Client-Server Architecture

NFS employs an architecture similar to a 3-tier Client-Server Architecture, i.e. it uses a server program, a client program and client/server stubs (acting like proxies) that use a protocol to communicate between the clients/servers over the network. NFS was designed so that the server required no clue as to how a sequence of NFS operations relate to one another - the client keeps track of all information (Fat Client). This is different from the 3-tier architecture that we studied last semester where the middle tier was in charge of information storage. The middle tier of NFS acts more like a translation layer. A detailed description of this architecture follows:

The NFS Server & Daemons

The role of the NFS server is to allow its disk file systems to be accessed (in other words "shared") by other machines (clients) on the network. The process whereby a server makes its file systems available to be shared is called exporting, and the directories that are made available are referred to as exported file systems.

In order to export a file system, the system administrator must edit a configuration file and specify three things:

• The full pathname of the directory to be exported
• The client machines that will have access to the exported directory
• Any access restrictions

The sequence of events is as follows:

1. At system start-up time, a system dependent program is invoked that opens and reads the information in this configuration file.
2. This program then informs the servers operating system kernel about the permissions applicable to each exported file hierarchy. 
3. Special background processes (mountd and nfsd) are invoked and wait to receive NFS client requests to access the server's file systems. 
4. After this process is complete, the server is ready to accept client requests to access its file systems.

• nfsd - Handles filesystem exporting and file access requests from remote systems. An NFS server---any system that makes its filesystem available to other computers---will run multiple instances of this daemon.
• biod - Performs NFS (block) I/O operations for client process. Multiple instances of this daemon typically run on NFS servers.
• rpc.mountd - Handles mount requests from remote systems.
• rpc.lockd - Manages file locking on both server and client systems.
• rpc.statd - Handles lock crash and recovery services (client and server).
• portmap - Facilitates initial connection between local and remote servers.

The NFS Client

• The client can obtain a list of file heirarchies available for mounting from the server.
• It accepts full pathnames that allow the client to identify a particular heirarchy.
• It authenicates each clients request and validates the clients permission to access the heirarchy.
• It returns a handle to the root directory of the heirarchy which the client uses in subsequent calls.

Mount Protocol

• The mount protocol authenicates a clients request for the handle to a root directory. 
• The client passes identification of the process requesting the mount and the server validates it.
• Once a file system is mounted the server just accepts RPC requests for the file handle. 
• If a file handle can be determined, any client can forge RPC's to manipulate the file.

A major advantage of the NFS client is its ability to transparently mount and access multiple network based file systems, making the mainframe, UNIX, NT and/or PC file system appear to the PC user as if it were a local drive. An enhanced client side service called the automounter automatically and transparently mounts and unmounts file systems on an "as needed" basis. From the user perspective, this creates an environment where server file systems are continuously accessible.

The NFS Protocol

The NFS protocol consists of a set of remote procedures enabling clients to manipulate remote files and directories on server systems as if they were local. Using the NFS protocol routines, clients send requests for file operations to servers, and servers respond by attempting to perform the operation (provided the user has proper permission) and then sending back successful results or error values. The NFS protocol includes a full spectrum of file operations such as read, write, rename, and mkdir.

Achieving Fast Error Recovery

One of the features mentioned in the Introduction to NFS was Fast Recovery from Failure. The NFS protocol was designed for fast error recovery. The parameters to each NFS procedure call contain all of the information necessary to complete it. This not only enables NFS to recover more quickly from system and network failures, it also makes NFS easier to administer.

Achieving Network Protocol Independence

NFS can run over multiple existing protocols such as UDP and TCP, as well as having the potential to run over new protocols in the future. The NFS protocol gains its network protocol independence by virtue of fact that it is built on top of the transport independent remote procedure call (RPC) technology.

Achieving Machine Indepenmdence

Because NFS utilizes the External Data Representation (XDR), it is machine and language independent. XDR defines the size, byte order, and alignment of basic data types such as integer, array, union, etc. so that data can be exchanged between systems with different byte ordering conventions. One can think of this layer as a sort of Virtual Machine.

Next: Achieving transparency with Proxy Pattern

Sources:

http://www.eecs.lehigh.edu/~zhz3/CSC350/NFS/nfs.html

http://userpages.umbc.edu/~jack/ifsm498d/nfs.html