Open System Services NFS Overview

B NFS Protocol Description
This appendix describes the NFS layered architecture and network services.
There are many similarities between the NFS services and the services offered by conventional file
systems that you are familiar with. The Network File System has, in fact, become an unofficial
industry-standard remote file system, because it offers all essential file-system features without relying
on any specific implementation platform.
Overview
The NFS protocol provides transparent remote access to shared filesets over networks. The NFS
protocol is designed to be independent of operating systems, network architecture, and transport
protocol. This independence is achieved through the use of Remote Procedure Call (RPC) primitives
built on top of the external data representation (XDR) standard. Implementations exist for a variety
of machines, from personal computers to supercomputers. The supporting mount protocol allows
the server to distribute remote access privileges to a restricted set of clients, thus allowing clients
to attach a remote directory tree at any point on a local file system.
Figure 4 shows the NFS protocols in the ISO Open Systems Interconnection (OSI) Model. Note
that NFS, XDR, and RPC are above the Transport Layer. New protocols, such as OSI, can be
“plugged in to” the RPC implementation without affecting applications that are using the higher-level
protocols.
Figure 4 NFS Protocols in the ISO Open Systems Interconnection (OSI) Model
Remote Procedure Call (RPC)
The RPC specification provides a procedure-oriented interface to remote services. Each server
supplies a program that is a set of procedures. The Network File System is one such program. The
host address, program number, and procedure number together specify one remote service
procedure. RPC does not depend on services provided by specific protocols, so it can be used
with any underlying transport protocol.
The RPC model is similar to the local procedure call model. In the local model, the caller places
parameters to a procedure in some well-known location (such as a result register). The caller then
transfers control to the procedure and eventually regains control. At that point, the results of the
procedure are extracted from the well-known location and the caller continues execution.
Like the local procedure call model, the RPC model has one thread of control that logically winds
through two processes: one is the caller process and the other is a server process. The caller process
sends a call message to the server process and waits (blocks) for a reply message. The call message
contains the procedure’s parameters, among other information. The reply message contains the
Overview 21