tyt12fi.htm

一个学习tcp/ip协议的教程

pcnfsd        150001  pcnfsd</FONT></PRE><P>This file shows the program name and its corresponding program number. The third column, when present, shows a program name that corresponds with the process name in the first column. The program numbers shown in this file are assigned by the RPC RFC and should be consistent across all implementations of RPC.<BR><BR><A ID=E70E47 NAME=E70E47></A><H5 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Port Mapper</B></FONT></CENTER></H5><BR><P>Connections between a client and server are over ports, each with its own number (port numbers are used in TCP/IP to define a connection). To prevent problems with port allocation using RPC, a <I>port mapper</I> was developed. Without the port mapper, a server could easily run out of available ports with only a few RPC connections active.<BR><P>The port mapper controls a table of ports and RPC programs using those ports. The port mapper itself has a dedicated port number (port 111 with both UDP and TCP). The ports available to RPC connections are assigned when the RPC program is initiated, at which time these port numbers are sent to the port mapper.<BR><P>When a client wants to use RPC, it sends a request to the server. This request follows the RPC header format seen in Figure 12.3 and includes the version number of RPC, the service number, and the protocol to be used. The port mapper can then allocate a suitable port number and return that number in a reply message to the client. Once a port number has been assigned for that client, it is maintained, so that all procedure requests come over that port until the application terminates. The port numbers might be maintained over several processes, so the port inquiry needs to be conducted only once between system power cycles.<BR><P>This procedure does have a drawback: the client must know the server's address. It cannot simply send out a generic request for a server with the services it is looking for. This has been overcome with some newly developed network file systems, although not NFS.<BR><BR><A ID=E69E153 NAME=E69E153></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>External Data Representation (XDR)</B></FONT></CENTER></H4><BR><P>The External Data Representation (XDR) is the method by which data is encoded within an RPC message (or other protocol systems, as well). There is no formal message header or protocol system for XDR, although the XDR RFC does define the method of encoding data.<BR><P>XDR is used to ensure that data from one system is compatible with others. It might seem that no formal definition is required, but consider the case of an EBCDIC-based machine communicating with an ASCII-based machine. XDR enables both ends to convert from their local data representation to a common format, removing any doubts about the meaning of the data. (EBCDIC to ASCII is not the major conversion problem. Some systems use high bits as significant, and others use low bits. Also, formats for defining types of numbers differ considerably.)<BR><P>The XDR format uses sequential bits written into a buffer, then formatted into a message and sent to the lower protocol layers. XDR relies on an 8-bit byte, with the lower bytes being the most significant. The RFC defines that all integer data types are converted to 4-byte integers, with an extended 64-bit <I>hyperinteger</I> format available. IEEE 32-bit formats are used for floating-point numbers, where the mantissa is the lower 23 bits, the exponent takes 8 bits, and the sign of the number is 1 bit. Where data takes less than 4 bytes for any type, padding is added to ensure 4-byte lengths.<BR><BLOCKQUOTE><BLOCKQUOTE><HR ALIGN=CENTER><BR><NOTE><IMG SRC=note.gif WIDTH = 75 HEIGHT = 46>A special C-like language called XDR has been developed to simplify the handling of XDR-format data. It can be used from within other programming languages.</NOTE><BR><HR ALIGN=CENTER></BLOCKQUOTE></BLOCKQUOTE><BR><A ID=E69E154 NAME=E69E154></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Network File System Protocol</B></FONT></CENTER></H4><BR><P>The NFS protocol is composed of a set of RPC procedures. It is not a protocol in the conventional sense of defining a complex handshaking process between two machines. Instead, it is a method of communicating information about a procedure to be run. NFS uses UDP and has a port number of 2049 assigned. This port number is nonsense; it arises from an error in the original implementation that could not be corrected subsequently because of compatibility issues. Because the port numbers are assigned by the port mapper, this number has no real meaning.<BR><P>NFS was designed to be a <I>stateless</I> protocol, meaning that the machines using NFS would not have to maintain state tables to use the protocol. Also, it was designed to be robust, meaning that after failures (of a connection or a machine) the system could recover quickly and easily.<BR><P>The NFS protocol is difficult to describe without introducing some programming, because the system is described in terms of the XDR language. This type of discussion is beyond the scope of this book; for more information, refer to the RFCs. However, it is possible to convey a sense of the protocol's contents through an overview of its capabilities and features.<BR><P>To understand the NFS procedures that comprise the protocol, it is necessary to examine the data structures and objects in the protocol. NFS defines a set of constants that are used to establish various parameters, such as the number of bytes in a path name, the maximum number of bytes in a read or write request, or the size of an NFS pointer. These are called <I>protocol constants</I> and should be the same for all implementations of NFS.<BR><BLOCKQUOTE><BLOCKQUOTE><HR ALIGN=CENTER><BR><NOTE><IMG SRC=note.gif WIDTH = 75 HEIGHT = 46>A <I>data object </I>is a set of variables or values that are combined in one entity, much as an entry in a telephone book is actually composed of a name, address, and telephone number. All three variables or values combine to form a single entry or object.</NOTE><BR><HR ALIGN=CENTER></BLOCKQUOTE></BLOCKQUOTE><P>Several data objects are used by NFS to define files and their attributes. Because NFS deals specifically with files, these objects are important to the protocol. One data object is the file handle (or fhandle), which uniquely identifies a file on the server. File handles are provided in all NFS messages that refer to the file. As with most NFS data types, the file handle is a 32-byte field of free format that is understandable by the server. For example, a UNIX file is uniquely defined by its device major and minor numbers and its inode number. The filename itself is not used.<BR><P>A data object is used for the file type (called ftype), which defines all the kinds of files known by NFS. These mimic the UNIX file types, including a regular file (any kind of data), a directory (which is a file entry in UNIX), links (which are several pointers under different names to the same file) and both block and character mode files.<BR><P>Also used is a data structure for the file attributes, called fattr<I>.</I> This defines the permissions of the file, the times of access, the owner, and several other parameters. This is necessary whenever a file read or write is performed, because the attributes must be correct to allow the procedure to continue. (The attributes can be changed by another NFS procedure called set attributes or sattr<I>.</I>)<BR><P>These data objects can be combined into a larger entity using a discriminating union. A <I>discriminating union </I>is a combination of several data objects that are given a single label. These discriminating unions can be thought of as a label followed by data, which might differ depending on the outcome of a procedure. For example, after a procedure has been executed, a discriminating union might be a label followed by either an error message or the result of the procedure, if it executes properly. The union, though, is referred to by the label and doesn't care about the contents in the data area. This type of structure is used to simplify programming.<BR><P>Seventeen procedures (and a NULL procedure) are defined within the NFS protocol. These procedures are summarized in Table 12.1. This book doesn't go into detail about the procedures, as they are not relevant to the level of discussion. The RFC covers them all in exhaustive detail.<BR><BR><P ALIGN=CENTER><CENTER><FONT COLOR=#000080><B>Table 12.1. NFS procedures.</B></FONT></CENTER><BR><CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Name</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Description</I></B></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Null<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Null procedure<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Fetch file attributes<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Returns the attributes of a file<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Set file attributes<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Sets the attributes of a file<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Read file system root<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Not used; now obsolete<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Lookup filename<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Returns the file handle corresponding to a filename<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Read contents of link<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Returns details of symbolic links to a file<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Read file<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Reads a file<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Write to cache<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Not used<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Write to file<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Writes a file<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Create file<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Creates a new file and returns the new file's handle<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Delete file<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Deletes a file<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Rename file<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Renames a file<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Generate link<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Creates a link to a file (same file system)<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Generate symbolic link<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Generates a symbolic link (across file systems)<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Create directory<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Creates a new directory<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Delete directory<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Removes a directory<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Read directory<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Returns a list of files in the directory<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Read file system attributes<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Returns information about the file system</FONT></TABLE></CENTER><BR><P>Programmers might have noticed the lack of any open and close file functions within NFS. This arises from the stateless nature of the protocol. When a file must be opened, the local NFS process handles it, not the remote process. This allows for better control of files and ports after failure of a machine or a connection.<BR><BR><A ID=E69E155 NAME=E69E155></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Mount Protocol</B></FONT></CENTER></H4><BR><P>In today's introduction I mentioned that NFS works by mounting an NFS server file system onto a client file system. As you have just seen, however, the NFS protocol is actually about file access and information, not connecting file systems. This file system mounting procedure is dealt with as a separate issue by the NFS product, using the Mount protocol. Mount uses UDP.<BR><P>The Mount protocol is involved in returning a file handle from the server to the client, enabling the client to access an area on the server file system. The protocol returns not only the file handle but also the name of the file system in which the requested file resides. Mount consists of a number of procedures that facilitate communications between the client and server, designed especially for dealing with files.<BR><P>A process called mountd takes care of handling the mount protocol at both ends of a connection. The mountd process maintains a list of machines and path names that are involved in a mount operation. Once a mount has been performed, NFS can continue operating without referring back to Mount at all. This lets Mount continue to modify its internal tables without affecting ongoing sessions. This can cause a problem if a client crashes and reconnects. The server still has the original connections listed in its internal Mount tables. To correct this problem, most NFS clients send a command (called UMNTALL, or unmount all) to all NFS servers when they boot.<BR><BLOCKQUOTE><BLOCKQUOTE><HR ALIGN=CENTER><BR><NOTE><IMG SRC=note.gif WIDTH = 75 HEIGHT = 46>The Mount protocol is involved only during the original connection between a client and a server. The mountd process keeps track of connections, but once the connection is established, the Mount protocol relinquishes all control to NFS. All NFS needs to access a file system is a valid file handle (which Mount provides when the connection is made).</NOTE><BR><HR ALIGN=CENTER></BLOCKQUOTE></BLOCKQUOTE><P>As mentioned earlier, the Mount protocol consists of a set of procedures. These are summarized in Table 12.2 and are self-explanatory.<BR><BR><P ALIGN=CENTER><CENTER><FONT COLOR=#000080><B>Table 12.2. Mount protocol procedures.</B></FONT></CENTER><BR><CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Name</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Description</I></B></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>NULL<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Null<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MNT<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Mounts a file system and returns the file handle and file system name<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>UMNT<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Unmounts a server file system, deleting the entry from the Mount table<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>UMNTALL<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Unmounts all server file systems used by the client and updates the Mount table<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>EXPORT<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Provides a list of exported file systems<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>DUMP<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Provides a list of the file systems on the server that are currently mounted on the client</FONT></TABLE></CENTER><BR><P>Some versions of NFS enable an automount capability, in which the remote file systems are mounted only when required. This prevents them from being attached for extended periods of time and simplifies administration. The process of automounting is completely transparent to the user.<BR><P>The automount capability is built upon NFS's procedures, but it performs a few clever tricks. The automounter is not part of NFS but is an application that sits on top of it. Symbolic links are the key to the automounter's operation.<BR><BR><A ID=E69E156 NAME=E69E156></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>File Locking</B></FONT></CENTER></H4><BR><P>Occasionally a system administrator wants to prevent access to an NFS-available file system. Such instances occur regularly during maintenance, software updates, or to protect data during a particular process. UNIX has the capability to lock a particular file by changing permissions, and the same can be done for file systems to some extent, but it would seem intuitive that locking a file system is more involved than simply locking a file or two. The capability to lock file systems from access was not developed with the original NFS product but was implemented as a parallel service after NFS became more widely available.<BR><BLOCKQUOTE><BLOCKQUOTE><HR ALIGN=CENTER><BR><NOTE><IMG SRC=note.gif WIDTH = 75 HEIGHT = 46>Separating functionality (such as file locking) into separate protocols or procedures is consistent with both the OSI and NFS philosophies. This also enables better portability and compatibility across platforms.</NOTE><BR><HR ALIGN=CENTER></BLOCKQUOTE></BLOCKQUOTE><P>File system locking is handled by several protocols and procedures, involving a few daemon processes. In the original file locking system developed by Sun Microsystems, a lock daemon called lockd was used. This requires that every RPC activity that involves a lock communicates with the process, even when it is on another machine. The communications between RPC and lockd use a protocol called Kernel Lock Manager (KLM), which rides on UDP.<BR><P>Whenever a lock procedure is called, lockd decides whether it can handle the task on the local machine or whether messages have to be sent to remote lockd processes (on other machines). Communications between different lockd processes are through another protocol called the Network Lock Manager (NLM). There are several versions of both KLM and NLM in use, with implementations available for most hardware platforms.<BR><P>A process called statd (status monitor) monitors the state of locks and handles queries against a locked file system. This is necessary so that a new query against a locked file system can be queued (if it is locked for a short time) or rejected (if the file system is locked for a while).<BR><P>There are several built-in protection systems for file locking, such as automatic timers to prevent infinite locking after a machine crash, conflicting requests for locks, and a short period for completion of existing procedures before a lock is completed. These are all defined and explained in the RFC.<BR><BR><A ID=E69E157 NAME=E69E157></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Remote Execution Service (REX)</B></FONT></CENTER></H4><BR><P>The Remote Execution Service (REX) is designed to enable a user to run commands on another machine with full environment variables, without incurring the overhead of processes such as Telnet, rlogin, or rsh. REX uses a daemon called rexd that runs on the server and employs NFS's services. (Remember that each machine can be both client and server, so most multitasking machines on a network can run rexd.) REX is commonly used when some applications are installed on only a few machines but should be available to all users.<BR><P>REX has an important advantage over the other UNIX utilities for this type of service. It enables access to the local machine's data while executing the command on the remote. This enables a user to run an application on another machine while accessing data files on the local machine. It also enables another machine's resources to be used without starting a user shell process or logging into the remote machine.<BR><P>To run an application or execute a command on a remote machine, the REX on command is used. The syntax adds the name of the machine on which the command is to be executed and the command to run. The following code gives an example of this:<BR><PRE>

<FONT COLOR=#000080>$ hostname

tpci_hpws4

$ cat file1

This is the file &quot;file1&quot; on &quot;tpci_hpws4&quot;.

This is the client machine.

$ on merlin hostname

merlin

$ rsh merlin cat file1

cat: cannot open file1

$ on merlin cat file1

This is the file &quot;file1&quot; on &quot;tpci_hpws4&quot;.

This is the client machine.</FONT></PRE><P>This example shows the remote machine executing a cat command on a local file. When the remote machine runs commands using on, an identical environment to the client is established on the remote, including user and group IDs and environment variables. So, if the remote machine in the previous example had a file called file1, but it was not in the search path of the process running the command, the system would still refer back to the client for the file.<BR><BR><A ID=E69E158 NAME=E69E158></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>rusers</B><B> and </B><B>spray</B></FONT></CENTER></H4><BR><P>Two utilities available to NFS users are simple examples of RPC programs. They are also useful to the user who wants to check the status of connections and the load on a remote machine.<BR><P>The spray program is similar to ping in that it sends a batch of messages across the network and waits for replies. Several supported options can configure the use of spray. When the spray command is issued with the -c option, it sends a supplied number of datagrams to the remote machine and times the results. A typical use is shown here:<BR><PRE>

<FONT COLOR=#000080>$ spray -c 200 beast

sending 200 packets of length 86 to beast...