Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

As you can see, XDR provides considerable data description capability. If you know the “C”

language, much of what is in that table is probably familiar to you. Unfortunately, I can't

really describe many of the more complex data types in the table above in detail without

turning this into a guide to C programming.

In addition to the above, XDR also provides a means of defining new data types, and a

method for specifying optional data. This provides even more flexibility beyond the large

number of specific types already specifically described. Each version of NFS has a slightly

different list of data types it supports.

NFS Client/Server Operation Using Remote Procedure Calls (RPCs)

Almost all applications deal with files and other resources. When a software program on a

particular computer wants to read a file, write a file or perform related tasks, it needs to use

the correct software instructions for this purpose. It would be inefficient to require each

software program to contain a copy of these instructions, so instead, they are encoded as

float 4

Floating-Point Number: A 32-bit signed floating-point number. 1 bit holds

the sign (positive or negative), 8 bits hold the exponent (power), in base 2,

and 23 bits hold the mantissa (fractional part of the number).

double 8

Double-Precision Floating-Point Number: The same as float but with

more bits to allow greater precision. 1 bit is for the sign, 11 bits for the

exponent and 52 bits for the mantissa.

quadruple 16

Quadruple-Precision Floating-Point Number: The same as float and

double but with still more bits to allow greater precision. 1 bit is for the sign,

15 bits for the exponent and 112 bits for the mantissa.

opaque Variable

Opaque Data: Data that is to be passed between devices without being

given a specific representation using XDR. The term opaque means that

the data is treated like a “black box” whose insides cannot be seen.

Obviously, any machines using this data type must themselves know how

to deal with it, since NFS does not.

string Variable String: A variable-length string of ASCII characters.

(array) Variable

Arrays: A group of any single type of the elements above, such as

integers, floating point numbers and so on, may be specified in an array to

allow many to be referenced as a single unit. They are not indicated using

a separate data type code.

struct Variable

Structure: An arbitrary structure containing other data elements from this

table. This allows the definition of complex data types.

union Variable

Discriminated Union: A complex form of structure that I cannot do justice

to with a short description here. ☺

void 0 Void: A “null” data type that contains nothing.

const 0

Constant: Doesn't declare data, just defines a constant value used in other

representations.

Table 182: NFS External Data Representation (XDR) Data Types (Page 2 of 2)

Data Type Code

Size

(bytes)

Description

standardized software modules, sometimes called procedures. To perform an action, a

piece of software calls the procedure; the procedure temporarily takes over for the main

program and performs a task such as reading or writing data. The procedure then returns

control of the program back to the software that called it, and optionally, returns data as

well.

Since the key concept of NFS was to make remote file access look like local file access, it

was designed around the use of a network-based version of the procedure calling method

just described. A software application that wants to do something with a file still makes a

procedure call, but it makes the call to a procedure on a different computer instead of the

local one. A special set of routines is used to handle the transmission of the call across the

network, in a way largely invisible to software performing the call.

This functionality could have been implemented directly in NFS, but instead Sun created a

separate session-layer protocol component called the Remote Procedure Call (RPC) speci-

fication, which defines how this works. RPC was originally created as a subcomponent of

NFS, but is generic enough and useful enough that it has been used for other client/server

applications in TCP/IP. For this reason, it is really considered in many respects a distinct

protocol.

Because RPC is the actual process of communicating in NFS, NFS itself is different from

many other TCP/IP protocols. Its operation can't be described in terms of specific message

exchanges and state diagrams the way a protocol like HTTP or DHCP or even TCP can,

because RPC does all of that. NFS is in fact defined in terms of a set of RPC server proce-

dures and operations that an NFS server makes available to NFS clients. These

procedures and operations each allow a particular type of action to be taken on a file, such

as reading from it, writing to it or deleting it.

RPC Operation and Transport Protocol Usage

When a client wants to perform some type of action on a file on a particular machine, it uses

RPC to make a call to the NFS server on that machine. The server accepts the request and

performs the action required, then returns a result code and possibly data back to the client,

depending on the request. The result code indicates if the action was successful. If it was,

the client can assume that whatever it asked to be done was completed. For example, in

the case of writing data, the client can assume the data has been successfully written to

long-term storage.

NFS can operate over any transport mechanism that has a valid RPC implementation at the

session layer. Of course in TCP/IP we have two transport protocols, UDP and TCP

. It's

interesting to see that NFS has seen an evolution of sorts in its use of transport protocol.

The NFSv2 standard says that it operates “normally” using UDP, and this is still a common

way that NFS information is carried. NFSv3 says that either UDP or TCP may be used, but

NFSv4 specifies TCP to carry data. The nominal registered port number for use by NFS is

2049, but in fact other port numbers are sometimes used for NFS, through the use of RPC's

“port mapper” capability.

Key Concept: NFS does not use a dedicated message format, like most other

protocols do. Instead, clients and servers use the Remote Procedure Call (RPC)

protocol to exchange file operation requests and data.

Client and Server Responsibilities in NFS

Since UDP is unreliable, the use of that protocol to transport important information may

seem strange. For example, we obviously don't want data that we are trying to write to a file

to be lost in transit. Remember, however, that UDP doesn't preclude the use of measures to

ensure reliable communications, it simply doesn't provide those capabilities itself. UDP can

be used by NFS because the protocol itself is designed to tolerate loss of transmitted data

and to recover from it.

Consistent with this concept, the general design of NFS puts most of the responsibility for

implementing the protocol on the client, not the server. As the NFSv3 standard says, “NFS

servers are dumb and NFS clients are smart.” What this means is that the servers focus

only on responding to requests, while clients must take care of most of the “nitty-gritty”

details of the protocol, including recovery from failed communications. This is in fact a

common requirement when UDP is used, because if a client request is lost in transit, the

server has no way of knowing that it was ever sent.

As mentioned in the NFS overview, NFS servers are designed to be “stateless”. In

simplified terms, this means that the NFS server does not keep track of the state of the

clients using it from one request to another. Each request is independent of the previous

one, and the server in essence has “no memory” of what it did before when it gets a new

command from a client. This again requires more “smarts” to be put into the clients, but has

the important advantage of simplifying recovery in the case that the server crashes. Since

there is nothing that the server was keeping track of for the client, there's nothing that can

be lost. This is an important part of ensuring that files are not damaged as a result of

network problems or congestion.

Client and Server Caching

Both NFS clients and servers can make use of caching to improve performance. Servers

may use caching to store recently-requested information in case it is needed again. They

may also use predictive caching, sometimes called prefetching. In this technique, a server

that receives a request to read a block of data from a file may load into memory the next

block after it, on the theory that it will likely be requested next. Client-side caching is used to

satisfy repeat NFS requests from applications while avoiding additional RPC calls. Like

almost everything else about NFS, caching is implemented much more thoroughly in NFS

version 4 than in the previous versions.

Key Concept: NFS is designed to be a stateless protocol, with intelligent clients and

relatively “dumb” servers that respond to requests and do not maintain status infor-

mation about what files are in use. NFS was originally designed to use UDP for

transport, for efficiency purposes. This requires that NFS clients take care of detecting lost

requests and retransmitting them. NFS version 4 uses TCP to take advantage of TCP’s

reliability and other features.

NFS Server Procedures and Operations

The actual exchange of information between an NFS client and server is performed by the

underlying Remote Procedure Call (RPC) protocol. NFS functionality is therefore described

not in terms of specific protocol operations, but by delineating the different actions that a

client may take on files residing on a server. In the original version of NFS, NFSv2, these

are called NFS server procedures.

Each procedure represents a particular action that a client may perform, such as reading

from a file, writing to a file, or creating or removing a directory. The operations performed on

the file require that the file be referenced using a data structure called a file handle. As the

name suggests, the file handle, like the handle of a real object, lets the client and server

“grasp” onto the file. The Mount protocol is used to mount a file system, to enable a file

handle to be accessed for use by NFS procedures.

NFS version 3 uses the same basic model for server procedures, but makes certain

changes. Two of the NFSv2 procedures were removed, and several new ones added to

support new functionality. The numbers assigned to identify each procedure were also

changed.

NFS Version 2 and Version 3 Server Procedures

Table 183 shows the server procedures defined in versions 2 and 3 of NFS. The table

shows the procedure numbers for both NFSv2 and NFSv3, as well as the name of each

procedure and a description of what it does. I have kept the descriptions short so the table

can serve as a useful summary of what NFS can do. They are listed in order of the

procedure number used in NFSv2.

Table 183: NFS Version 2 and Version 3Server Procedures (Page 1 of 3)

Proce-

dure #

(v2)

Proce-

dure #

(v3)

Procedure

Name

Procedure

Summary

Description

00 null Do Nothing Dummy procedure provided for testing purposes.

1 1 getattr

Get File

Attributes

Retrieves the attributes of a file on a remote server.

22 setattr

Set File

Attributes

Sets (changes) the attributes of a file on a remote

server.

3 — root

Get

Filesystem

Root

(obsolete)

This procedure was originally defined to allow a client

to find the root of a remote file system, but is now

obsolete. This function is instead now implemented as

part of the Mount protocol. It was removed in NFSv3.

43 lookup

Look Up File

Name

Returns the file handle of a file for the client to use.

5 5 readlink

Read From

Symbolic Link

Reads the name of a file specified using a symbolic

link.

66 read

Read From

File

Reads data from a file.

7 — writecache

Write To

Cache

Proposed for future use in version 2 but abandoned

and removed from version 3.

87 write Write To File Writes data to a file.

9 8 create Create File Creates a file on the server.

10 12 remove Remove File Deletes a file from the server.

11 14 rename Rename File Changes the name of a file.

12 15 link

Create Link To

File

Creates a “hard' (non-symbolic) link to a file.

13 10 symlink

Create

Symbolic Link

Creates a symbolic link to a file.

14 9 mkdir

Create

Directory

Creates a directory on the server.

15 13 rmdir

Remove

Directory

Deletes a directory.

16 16 readdir

Read From

Directory

Reads the contents of a directory.

17 — statfs

Get File

System

Attributes

Provides to the client general information about the

remote file system, including the size of the file system

and the amount of free space remaining.

In NFSv3 this was replaced by fsstat and fsinfo.

—4 access

Check Access

Permission

(New in NFSv3.) Determines the access rights that a

user has for a particular file system object.

— 11 mknod

Create A

Special

Device

(New in NFSv3.) Creates a special file such as a

named pipe or device file.

—17readdirplus

Extended

Read From

Directory

(New in NFSv3.) Retrieves additional information from

a directory.

Table 183: NFS Version 2 and Version 3Server Procedures (Page 2 of 3)

Proce-

dure #

(v2)

Proce-

dure #

(v3)

Procedure

Name

Procedure

Summary

Description

NFS Version 4 Server Procedures and Operations

It is common that a client may want to perform multiple actions on a file: several consec-

utive reads, for example. One of the problems with the server procedure system in NFSv2

and NFSv3 is that each client action required a separate procedure call. This was

somewhat inefficient, especially when NFS was used over a high-latency link.

To improve the efficiency of server procedures, NFS version 4 makes a significant change

to the way that server procedures are implemented. Instead of each client action being a

separate procedure, a single procedure called compound is defined. Within this

“compound” procedure, a large number of server operations are encapsulated. These are

all sent as a single unit and the server interprets and follows the instructions in each

operation in sequence.

This change means there are actually only two RPC procedures in NFSv4, as shown in

Table 184.

— 18 fsstat

Get Dynamic

File System

Information

(New in NFSv3.) Returns volatile (dynamic) file system

status information such as the current amount of file

system free space and the number of free file slots.

—19 fsinfo

Get Static File

System

Information

(New in NFSv3.) Returns static information about the

file system, such as general data about how the file

system is used, and parameters for how requests to

the server should be structured.

— 20 pathconf

Retrieve

POSIX

Information

(New in NFSv3.) Retrieves additional information for a

file or directory.

—21 commit

Commit

Cached Data

On A Server

To Stab le

Storage

(New in NFSv3.) Flushes any data that the server is

holding in a write cache to storage. This is used to

ensure that any data that the client has sent to the

server but that the server has held pending write to

storage is in fact written out.

Table 184: NFS Version 4 Server Procedures

Procedure #

Procedure

Name

Procedure

Summary

Description

0 null Do Nothing Dummy procedure provided for testing purposes.

1 compound

Compound

Operations

Combines a number of NFS operations into a single

request, as described above.

Table 183: NFS Version 2 and Version 3Server Procedures (Page 3 of 3)

Proce-

dure #

(v2)

Proce-

dure #

(v3)

Procedure

Name

Procedure

Summary

Description

All the real client actions are defined as operations within the compound procedure, as

shown in Table 185. You'll notice that the number of NFSv4 operations is much larger than

the number of procedures in NFSv2 and NFSv3. This is due both to the added features in

version 4 and the fact that NFSv4 incorporates functions formerly performed by the

separate Mount protocol into NFS itself.

Table 185: NFS Version 4 Server Operations (Page 1 of 2)

Operation #

Operation

Name

Operation

Summary

Description

3 access

Check Access

Rights

Determines the access rights a user has for an object.

4 close Close File Closes a file.

5 commit

Commit Cached

Data

Flushes any data that the server is holding in a write

cache to storage, to ensure that any pending data is

permanently recorded.

6 create

Create A Non-

Regular File

Object

This is similar to the mknod procedure in NFSv3; it

creates a “non-regular” (special) object file. (Regular

files are created using the open operation.)

7 delepurge

Purge Delegations

Awaiting

Recovery

NFSv4 has a feature where a server may delegate to

a client responsibility for certain files. This operation

removes delegations awaiting recovery from a client.

8 delegreturn Return Delegation

Returns a delegation from a client to the server that

granted it.

9 getattr Get Attributes Obtains the attributes for a file.

10 getfh

Get Current

Filehandle

Returns a file handle, which is a logical object used to

allow access to a file.

11 link

Create Link To A

File

Creates a “hard' (non-symbolic) link to a file.

12 lock Create Lock

Creates a lock on a file. Locks are used to manage

access to a file, for example, to prevent two clients

from trying to write to a file simultaneously and thus

corrupting it.

13 lockt Te s t Fo r Loc k

Tests for the existence of a lock on an object and

returns information about it.

14 locku Unlock File Removes a lock previously created on a file.

15 lookup Lookup Filename Looks up or finds a file.

16 lookupp

Lookup Parent

Directory

Returns the filehandle of an object's parent directory.

17 nverify

Verify Difference

In Attributes

Checks to see if attributes have changed on a file.

18 open

Open A Regular

File

Opens a file.

19 openattr

Open Named

Attribute Directory

Opens an attribute directory associated with a file.

20 open_confirm Confirm Open Confirms information related to an opened file.

open_

downgrade

Reduce Open File

Access

Adjusts the access rights for a file that is already open.

22 putfh

Set Current

Filehandle

Replaces one filehandle with another.

23 putpubfh

Set Public

Filehandle

Sets the current filehandle to be the “public” filehandle

of the server. This may or may not be the same as the

root filehandle (see below).

24 putrootfh

Set Root

Filehandle

Sets the current filehandle to be the root of the

server's file system.

25 read Read From File Reads data from a file.

26 readdir Read Directory Reads the contents of a directory.

27 readlink

Read Symbolic

Link

Reads the name of a file specified using a symbolic

link.

28 remove

Remove

Filesystem Object

Removes (deletes) an object.

29 rename

Rename Directory

Entry

Changes the name of an object.

30 renew Renew A Lease

Renews an NFS delegation made by a server. (Note

that these leases have nothing to do with DHCP

leases!)

31 restorefh

Restore Saved

Filehandle

Allows a filehandle previously saved to be made the

current filehandle.

32 savefh

Save Current

Filehandle

Allows a filehandle to be saved so it can later be

restored when needed.

33 secinfo

Obtain Available

Security

Retrieves NFS security information.

34 setattr Set Attributes Changes one or more attributes of a file.

35 setclientid Negotiate Clientid

Allows a client to communicate information to the

server regarding how the client wants to use NFS.

setclientid_

confirm

Confirm Clientid

Used to confirm the results of a previous negotiation

using setclientid.

37 verify

Verify Same

Attributes

Allows a client to verify certain attributes before

proceeding with a particular action.

38 write Write To File Writes data to a file.

release_

lockowner

Release

Lockowner State

Used by a client to tell a server to release certain infor-

mation related to file locks.

10044 illegal Illegal Operation

A “placeholder” (dummy) operation used to support

error reporting when an invalid operation is used in a

request from a client.

Table 185: NFS Version 4 Server Operations (Page 2 of 2)

Operation #

Operation

Name

Operation

Summary

Description

Key Concept: File operations in NFS are carried out using NFS server procedures.

In versions 2 and 3 of NFS, each procedure performs one action, such as reading

data from a file. In version 4, a special compound action is defined that allows many

individual operations to be sent in a single request to a server.

NFS File System Model and the Mount Protocol

Since NFS is used by a client to simulate access to remote directories of files as if they

were local, the protocol must “present” the files from the remote system to the local user.

Just as files on a local storage device are arranged using a particular file system, NFS too

uses a file system model to represent how files are shown to a user.

The NFS File System Model

The file system model used by NFS is the same one that most of us are familiar with: a

hierarchical arrangement of directories that contain files and subdirectories. The top of the

hierarchy is the root, which contains any number of files and first level directories. Each

directory may contain more files or other directories, allowing an arbitrary tree structure to

be created.

A file can be uniquely specified by using its file name and a path name that shows the

sequence of directories one must traverse from the root to find the file. Since NFS is

associated with UNIX, files in NFS discussions are usually shown in UNIX notation; for

example, “/etc/hosts”. The same basic tree idea can also be expressed using the method

followed by Microsoft operating systems: “C:\WINDOWS\HOSTS”.

The Mount Protocol

Before NFS can be used to allow a client to access a file on a remote server, the client must

be given a way of accessing the file. This means that a portion of the remote file system

must be made available to the client, and the file opened for access. A specific decision

was made when NFS was created to not put file access, opening and closing functions into

NFS proper. Instead, a separate protocol was created to work with NFS, so that if in the

future the method of providing file access needed to be changed, it wouldn't require

changes to NFS itself. This separate mechanism is called the Mount Protocol, and is

described in Appendix A of RFC 1094 (NFSv2). Note that while functionally distinct, Mount

is considered part of the overall NFS package.

When NFS was revised to version 3, the Mount Protocol was similarly modified. The NFSv3

version of the Mount Protocol is defined in Appendix I of RFC 1813 (NFSv3). It contains

some changes to how the protocol works, but the overall operation of the two versions of

Mount is pretty much the same.

The term “mount” is actually an analog to a hardware term that refers to making a physical

storage volume available. In the “olden dayse” storage devices were usually removable

disk packs, and to use one you mounted it onto a drive unit. In a similar manner, NFS

resources are logically mounted using the Mount protocol, which makes the shared file

system available to the client. A file can then be opened and a file handle returned to the

NFS client so it can reference the file for operations such as reading and writing.

Key Concept: Versions 2 and 3 of NFS do not include procedures for opening or

closing resources on a remote server. Before NFS tasks can be accomplished on

these versions, the special Mount protocol must be employed to mount a filesystem

and create a file handle to access a file on it; the protocol is also used to unmount the file

system when no longer required. The Mount protocol is implemented in a manner very

similar to NFS itself, defining procedures that use RPC and XDR. In version 4 of NFS,

Mount is no longer needed; the tasks it performs are implemented as NFSv4 operations.

Mount Protocol Server Procedures

The actual implementation of the Mount protocol is very similar to that of NFS itself. Like

NFS, the Mount protocol uses XDR to define data types to be exchanged between client

and server, and RPC to define a set of server procedures that clients may use to perform

different operations. The main difference between Mount and NFS is simply that Mount

defines procedures related to opening and closing filesystems rather than file access

operations. Table 186 shows the server procedures used in the Mount protocol.

As mentioned in other topics in this section, NFS version 4 does away with the notion of a

separate Mount protocol, incorporating file mounting operations into NFS directly.

Table 186: NFS Mount Protocol Server Procedures

Procedure #

Procedure

Name

Procedure

Summary

Description

0 null Do Nothing Dummy procedure provided for testing purposes.

1 mnt

Add Mount

Entry

Performs a mount operation by mapping a path on a

server to a file handle for the client to use.

2 dump

Return Mount

Entries

Returns a list of remotely mounted file systems.

3 umnt

Remove

Mount Entry

Performs an “unmount” by removing a mount entry. (It

should be “dismount”. Techies are rarely into grammar. ☺)

4 umntall

Remove All

Mount Entries

Removes all mount entries, thus eliminating all mounted

file systems between server and client.

5 export

Return Export

List

Returns a list of exported file systems and indicates which

clients are allowed to mount them. This is used to let the

client see what served file systems are available for use.