> U Qm 0 7 '
`
`< mmI
`
`‘—
`
`m -
`
`<
`
`:JA.)
`
`0"
`
`T7
`
`m i
`
`n
`
`EC
`
`0 / >1
`
`..
`
`Sldlo Dull“ “b“
`
`(W'wllhtmn
`
`TOP/1P
`1111181313
`VOhHHG 1
`The PrOtOCOIS
`
`W. Richard S’réVenS
`
`n O Eu C j Z O m C
`
`L“AJ
`
`a‘
`
`L/‘J
`
`Petitioner Microsoft Corporation - Ex. 1017, p.1
`
`

`

`UNIX is a technology trademark of XIOpen Company, Ltd.
`
`The publisher offers discounts on this book when ordered in quantity for special sales.
`For more information please contact:
`Corporate & Professional Publishing Group
`AddisonwWesley Publishing Company
`One Jacob Way
`Reading, Massachusetts 01867
`
`Library of Congress Cataloging-in-Publicatiou Data
`Stevens, W. Richard
`TCP/IP Illustrated: the protocolle. Richard Stevens.
`p. cm. — (Addison-Wesley professional computing series)
`Includes bibliographical references and index.
`ISBN 0-201-63346-9 (v. 1)
`1.TCPIIP (Computer network protocol) I. Title. II. Series.
`TK5105.SSS74 1994
`004.6’2—dc20
`
`Copyright Q 1994 Addison Wesley Longman, Inc.
`
`All rights reserved. No part of this publication may be reproduced, stored in a retrieval system,
`or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or
`otherwise, without prior written permission of the publisher. Printed in the United States of
`America. Published sn‘nultarteously in Canada
`r
`
`Text printed on recycled and acid-free paper.
`ISBN 0201633469
`161718192021 MA 03 02 0100
`
`February 2000
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.2
`
`

`

`29
`
`NFS: Network File System
`
`Introduction
`
`In this chapter we describe NFS, the Network File System, another popuiar application
`that provides transparent file access for client applications. The building block of NFS is
`Sun RPC: Remote Procedure Call, which we must describe first.
`Nothing special need be done by the client program to use NFS. The kernel detects
`that the file being accessed is on an NFS server and automatically generates the RFC
`calls to access the file.
`
`Our interest in NFS is not in all the details on file access, but in its use of the Intemet
`protocols, especially UDP.
`
`.292 Sun Remote Procedure Call
`
`Most network prograrmning is done by writing application programs that call system-
`provided functions to perform specific network operations. For example, one function
`performs a TCP active open, another performs a TCP passive open, another sends data
`across a TCP connection, another sets specific protocol options (enable TCP’s keepalive
`timer), and so on. In Section 1.15 we mentioned that two popular sets of functions for
`network programming (called APIs) are sockets and TLI. The API used by the client
`and the API used by the server can be different, as can the operating systems running
`on the client and server. It is the communication protocol and application protocol that
`determine if a given client and server can communicate with each other. A Unix client
`written in C using sockets and TCP can communicate with a mainframe server written
`in COBOL using some other API and TCP, if both hosts are connected across a network
`and both have a TCPrf 1P implementation.
`
`461
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.3
`
`

`

`
`NFS: Network File System
`
`
`Chapter 29
`—~—-..
`
`
`Typically the client sends conunands to the server, and the server sends replies back
`to the client. All the applications we’ve looked at so far aPing, Traceroute, routing dae-
`mons, and the clients and servers for the DNS, TFI'P, BOOTP, SNMP, Telnet, FTP, and
`SMI'P—are built this way.
`RPC, Remote Procedure Call, is a different way of doing network programming, A
`client program is written that just calls functions in the server program. This is how it
`appears to the programmer, but the following steps actually talg place.
`
`I. When the client calls the remote procedure, it’s really calling a function on the
`local host that’s generated by the RPC package. This function is called the client
`stub. The client stub packages the procedure arguments into a network mes-
`sage, and sends this message to the server.
`2. A server stub on the server host receives the network message. It takes the argu-
`ments from the network message, and calls the server procedure that the appli-
`cation programmer wrote.
`3. When the server function returns, it returns to the server stub, which takes the
`return values, packages them into a network message, and sends the message
`back to the client stub.
`
`4. The client stub takes the return values from the network message and returns to
`the client application.
`
`The network programming done by the stubs and the RPC library routines uses an API
`such as sockets or TLI, but the user application—the client progr
`, and the server pro-
`cedures called by the client—never deal with this API. The client application just calls
`the server procedures and all the network programming details are hidden by the RPC
`package, the client stub, and the server stub.
`An RPC package provides numerous benefits.
`
`2.
`
`1. The programming is easier since there is little or no network programming
`involved. The application programmer just writes a client program and the
`server procedures that the client calls.
`If an unreliable protocol such as UDP is used, details like timeout and retrans-
`mission are handled by the RPC package. This simplifies the user application.
`3. The RPC library handles any required data translation for the arguments and
`return values. For example, if the arguments consist of integers and floating
`point numbers, the RPC package handles any differences in the way integers
`and floating point numbers are stored on the client and server. This simplifies
`coding clients and servers that can operate in heterogeneous environments.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Details of RPC programming are provided in Chapter 18 of [Stevens 1990]. Two
`popular RPC packages are Sun RPC and the RPC package in the Open Software Foun-
`dation’s (OSF) Distributed Computing Environment (DCE). Our interest in RPC is to
`
`see what the procedure call and procedure return messages look like for the Sun RPC
`package, since it’s used by the Network File System, which we describe in this chapter.
`
`Version 2 of Sun RPC is defined in RFC 1057 [Sun Microsystems 1988a].
`
`
`
`
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.4
`
`

`

`Sun Remote Procedure Call
`
`
`463
`
`Sun RPC comes in two flavors. One version is built using the sockets API and works
`with TCP and UDP. Another, called TI-RPC (for ”transport independent”), is built
`using the TLI API and works with any transport layer provided by the kernel. From
`our perspective the two are the same, although we talk only about TCP and UDP in this
`chapter.
`Figure 29.1 shewsthetematafan RPC proredurerafl mange, When UDP is used.
`
` 20 bytes
`iii-##0##-
`
`UDP header
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`common for
`all Sun RPC
`procedure calls
`
`
`
`
`up to 405 bytes
`
`up to 408 bytes
`
`
`
`
`
`
`procedure being called
`
`procedure
`parameters
`
`depends on specific
`
`Figure 29.1 Format of RPC procedure rail message as a UDP datagram
`
`The IP and UDP headers are the standard ones we showed earlier (Figures 3.1 and 11.2).
`What follows after the UDP header is defined by the RPC package.
`The transaction ID (XID) is set by the client and returned by the server. When the
`client receives a reply it compares the XID returned by the server with the XID of the
`request it sent. If they don’t match, the client discards the message and waits for the
`next one from the server. Each time the client issues a new RPC, it changes the XID.
`But if the client retransmits a previously sent RPC (because it hasn’t received a reply),
`the XID does not change.
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.5
`
`

`

`NFS: Network File System
`
`Chapter 29
`
`
`
`
`
`
`
`
`
`
`The call variable is 0 for a call, and 1 for a reply. The current RPC version is 2. The
`next three variables, program number, version number, and procedure number, identify the
`specific procedure on the server to be called.
`The credentials identify the client.
`In some instances nothing is sent here, and in
`other instances the numeric user ID and group IDs of the client are sent. The server can
`look at the credentials and determine if it will perform the request or not. The verifier is
`used with Secure RPC, which uses DES encryption. Although the credentials and veri-
`
`fierarevariable-lengthfisldsflmirlengflqisencededas pretefmefield.
`
`Following this are the procedure parameters. The format of these depends on the
`
`definition of the remote procedure by the application. How does the receiver (the
`
`server stub) know the size of the parameters? Since UDP is being used, the size of the
`
`UDP datagram, minus the length of all the fields up through the verifier, is the size of
`
`the parameters. When TCP is used instead of UDP, there is no inherent length, since
`
`TCP is a byte stream protocol, without record boundaries. To handle this, a 4-byte
`
`length field appears between the TCP header and the XID, telling the receiver how
`
`many bytes comprise the RPC call. This allows the RPC call message to be sent in mul-
`
`tiple TCP segments, if necessary. (The DNS uses a similar technique; see Exercise 14.4.)
`Figure 29.2 shows the format of an RPC reply. This is sent by the server stub to the
`client stub, when the remote procedure returns.
`
`
`
`
`
`
`
`
`
`
`
`UDP header
`
`transaction ID {KID}
`
`reply (1}
`
`( map
`
`I
`
`
`
`
`accept status (0=success)
`
`
`
`
`
`
`
`
`
`procedure
`results
`
`20 bytes
`
`8
`
`4
`
`4
`
`4
`
`N
`
`all Sun RPC
`
`d
`d
`.
`epen s on
`spectfic procedure
`
`Figure 29.2 Format of RFC procedure reply message as a UDP datagz'am.
`
`The XID in the reply is just copied from the XID in the call. The reply is 1, which we said
`differentiates this message from a call. The status is 0 if the call message was accepted.
`(The message can be rejected if the RPC version number isn’t 2, or if the server cannot
`authenticate the client.) The verifier is used with secure RPC to identify the server.
`
`
`
`
`
`
`
`
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.6
`
`

`

`Port Mapper
`
`465
`
`The accept status is 0 on success. A nonzero value can indicate an invalid version
`number or an invalid procedure number, for example. As with the RPC call message, if
`TCP is used instead of UDP, a 4*byte length field is sent between the TCP header and
`the XID.
`
`29.3 XDFI: External Data Representation
`
`XDR, External Data Representation, is the standard used to encode the values in the RPC
`call and reply messages—the RPC header fields iXID, program number, accept status,
`etc.), the procedure parameters, and the procedure results. Having a standard way of
`encoding all these values is what lets a client on one system call a procedure on a sys-
`tem with a different architecture. XDR is defined in RFC 1014 [Sun Microsystems 1987].
`XDR defines numerous data types and exactly how they are transmitted in an RPC
`message (bit order, byte order, etc.). The sender must build an RPC message in XDR
`format, then the receiver converts the XDR format into its native representation. We
`see, for example, in Figures 29.] and 29.2, that all the integer values we show (XID, call,
`program number, etc.) are 4*byte integers. Indeed, all integers occupy 4 bytes in XDR.
`Other data types supported by XDR include unsigned integers, booleans, floating point
`numbers, fixed-length arrays, variable-length arrays, and structures.
`
`_ 29.4 Port Mapper
`
`The RPC server programs containing the remote procedures use ephemeral ports, not
`well-known ports. This requires a “registrar" of some form that keeps track of which
`RPC programs are using which ephemeral ports. In Sun RPC this registrar is called the
`port mapper.
`
`The term "port“ in this name originates from the TCP and UDP port numbers, features of the
`Internet protocol suite. Since TI-RPC works over any transport layer, and not just TCP and
`UDP, the name of the port mapper in systems using TI-RPC {SVR4 and Solaris 2.2, for exam—
`ple) has become rpcbind. We'll continue to use the more familiar name of port mapper.
`
`Naturally, the port mapper itself must have a well-known portz- UDP port 111 and
`TCP port 111. The port mapper is also just an RPC server program. It has a program
`number (100000), a version number (2), a TCP port of 111, and a UDP port of 111.
`Servers register themselves with the port mapper using RPC calls, and chants query the
`port mapper using RPC calls. The port mapper provides four server procedures:
`
`1. PMAPPROCVSET. Called by an RPC server on startup to register a program
`number, version number, and protocol with a port number.
`2. PMAPPROCHUNSET. Called by server to remove a previously registered
`mapping.
`
`3. PMAPPROC__GETPORT. Called by an RPC client on startup to obtain the port
`number for a given program nLunber, version number, and protocol.
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.7
`
`

`

`NFS: Network File System
`
`Chapter 29
`
`4. PMAPPROC_DUMP. Returns all entries (program number, version number,
`protocol, and port number) in the port mapper database.
`
`When an RPC server program starts, and is later called by an RPC client program,
`the following steps take place.
`
`1. The port mapper must be started first, normally when the system is boot-
`strapped. it creates; E1“ and pointanddoesa passire open on TCP port 11L_..
`It also creates a UDP end point and waits for a UDP datagram to arrive for UDP
`port 111.
`
`2. When the RFC server program starts, it creates a TCP end point and a UDP end
`point for each version of the program that it supports.
`(A given RPC program
`can support multiple versions. The client specifies which version it wants when
`it calls a server procedure.) An ephemeral port number is bound to both end
`points. (It doesn't matter whether the TCP port number is the same or different
`from the UDP port number.) The server registers each program, version, proto-
`col, and port number by making a remote procedure call to the port mapper's
`PMAPPROC‘SET procedure.
`
`it calls the port mapper’s PMAP-
`3. When the RFC client program starts,
`PROC_GETPORT procedure to obtain the ephemeral port number for a given
`program, version, and protocol.
`
`If
`4. The client sends an RPC call message to the port number returned in step 3.
`UDP is being used, the client just sends a UDP datagram containing an RFC call
`message (Figure 29.1) to the server’s UDP port number. The server responds by
`sending a UDP datagram containing an RPC reply message (Figure 29.2) back to
`the client.
`
`It TCP is being used, the client does an active open to the server‘s TCP port
`number, and then sends an RPC call message across the connection. The server
`responds with an RPC reply message across the connection.
`
`(It calls the
`The program rpcinf0(8) prints out the port mapper’s current mappings.
`port mapper’s PMAPPROC_DUMP procedure.) Here is some typical output:
`sun % lusr/etc/rpcinfo -p
`program vers proto
`port
`100005
`1
`top
`702 mountd
`100005
`1
`udp
`699 mountd
`100005
`2
`top
`702 mountd
`100005
`2
`udp
`699 mountd
`
`nwnntdamnonjbrhflE
`
`100003
`
`100021
`100021
`100021
`100021
`100021
`100021
`
`2
`
`1
`1
`2
`2
`3
`3
`
`udp
`
`top
`udp
`top
`udp
`top
`udp
`
`2049 nfs
`
`NFSEwdf
`
`NFS Jock manager
`
`709
`1036
`721
`1039
`713
`1037
`
`nlockrngr
`nlockmgr
`nlockmgr
`nlockmgr
`nlockmgr
`nlockmgr
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.8
`
`

`

`NFS Protocol
`
`45?
`
`We see that some programs do support multiple versions, and each combination of a
`program number, version number, and protocol has its own port number mapping
`maintained by the port mapper.
`Both versions of the mount daemon are accessed through the same TCP port num-
`ber (702) and the same UDP port number (699), but each version of the lock manager
`has its own port number.
`
`29.5 NFS Protocol
`
`NFS provides transparent file access for clients to files and filesystems on a server. This
`differs from FTP (Chapter 27), which provides file transfer. With FTP a complete copy of
`the file is made. NFS accesses only the portions of a file that a process references, and a
`goal of NFS is to make this access transparent. This means that any client application
`that works with a local file should work with an NFS file, without any program changes
`whatsoever.
`
`NFS is a client—server application built using Sun RPC. NFS clients access files on
`an NFS server by sending RPC requests to the server. While this could be done using
`normal user processes—that is, the NFS client could be a user process that makes
`explicit RPC calls to the server, and the server could also be a user process—NFS is nor-
`mally not implemented this way for two reasons. First, accessing an NFS file must be
`transparent to the client. Therefore the NFS client calls are performed by the client
`operating system, on behalf of client user processes. Second, NFS servers are imple-
`mented within the operating system on the server for efficiency. If the NFS server were
`a user process, every client request and server reply (including the data being read or
`written) would have to cross the boundary between the kernel and the user process,
`which is expensive.
`In this section we look at version 2 of NFS, as documented in RFC 1094 [Sun
`Microsystems 1988b]. A better description of Sun RPC, XDR, and NFS is given in
`[XIOpen 1991]. Details on using and administering NFS are in [Stern 1991]. The speci-
`fications for version 3 of the NFS protocol were released in 1993, which we cover in Sec-
`tion 29.7.
`
`Figure 29.3 shows the typical arrangement of an NFS client and an NFS server.
`There are many subtle points in this figure.
`
`It is transparent to the client whether it's accessing a local file or an NFS file.
`The kernel determines this when the file is opened. After the file is opened, the
`kernel passes all references to local files to the box labeled "local file access,”
`and all references to an NFS file are passed to the ”NFS client" box.
`2. The NFS client sends RPC requests to the NFS server through its TCP! IP mod-
`ule. NFS is used predominantly with UDP, but newer implementations can also
`use TCP.
`
`3. The NFS server receives client requests as UDP datagrams on port 2049.
`Although the NFS server could use an ephemeral port that it then registers with
`the port mapper, UDP port 2049 is hardcoded into most implementations.
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.9
`
`

`

`NFS: Network File System
`4—...— ._.._.__
`
`Chapter 29
`
`
`
`from being serviced. To han-
`-—that is, there are really multiple
`'
`'
`NFS servers running inside the server kernel. H
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.10
`
`

`

`NFS really consists of more than just the NFS protocol. Figure 29.4 shows the vari-
`ous RPC programs normally used with NFS.
`
`NFS Protocol
`
`6&9
`
`.
`
`.
`
`Program
`
`Version
`
`port mapper
`NFS
`mount
`lock manager
`
`100000
`100003
`100005
`100021
`
`2
`2
`1
`1, 2, 3
`
`
`
`
`Number of
`
`procedures
`
`
`
`
`
`4
`15
`5
`
`Figure 29.4 Various RPC programs used with NFS.
`
`The versions we show in this figure are the ones found on systems such as SunOS 4.1.3.
`Newer implementations are providing newer versions of some of the programs. Solaris 2.2,
`for example, also supports versions 3 and 4 of the port mapper, and version 2 of the mount
`daemon. SV'R4 also supports version 3 of the port mapper.
`
`The mount daemon is called by the NFS client host before the client can access a
`filesystem on the server. We discuss this below.
`The lock manager and status monitor allow clients to lock portions of files that
`reside on an NFS server. These two programs are independent of the NFS protocol
`because locking requires state on both the client and server, and NFS itself is stateless on
`the server.
`(We say more about NFS’s statelessness later.) Chapters 9, 10, and 11 of
`[X/Open 1991] document the procedures used by the lock manager and status monitor
`for file locking with NFS.
`
`File Handles
`
`A fundamental concept in NFS is the file handle. It is an opaque object used to reference a
`file or directory on the server. The term opaque denotes that the server creates the file
`handle, passes it back to the client, and then the client uses the file handle when access-
`ing the file. The client never looks at the contents of the file handle—its contents only
`make sense to the server.
`
`Each time a client process opens a file that is really a file on an NFS server, the NFS
`client obtains a file handle for that file from the NFS server. Each time the NFS client
`
`reads or writes that file for the user process, the file handle is sent back to the server to
`identify the file being accessed.
`Normal user processes never deal with file handles—it is the NFS client code and
`the NFS server code that pass them back and forth.
`In version 2 of NFS a file handle
`occupies 32 bytes, although with version 3 this changes from a fixed-length field to a
`variable-length field of up to 68 bytes.
`
`Unix servers normally store the following information in the file handle: the filesystem identi-
`fier (the major and minor device numbers of the filesystem), the i-node number (a unique
`number within a filesystem), and an i-node generation number (a number that changes each
`time an i—node is reused for a different file).
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.11
`
`

`

`
`NFS: Network File System
`
`.-
`
`Chapter 29
`._._.— .— .—._ .—
`
`Mount Protocol
`
`The client must use the NFS mount protocol to mount a server’s filesystem, before the
`client can access files on that filesystem. This is normally done when the client is boot-
`strapped. The end result is for the client to obtain a file handle for the server’s file-
`system.
`Figure 29.5 shows the sequence of steps that takes place when a Unix client issues
`ttremounrtfijr'command, spedfymgan N173 mount.
`
`—
`
`
`user process
`user process
`
`user process
`
`system
`call
`
`
`
`t -ort# RPC request
` 3 RFC reply w/port#
` (4) mount RFC request
`
`client kernel
`L ________ J
`
`I
`
` 5 RFC reply w/file handle
`
`L. ______531395 1339131______ J
`
`Figure 29.5 Mount protocol used by Unix mount cammand.
`
`The following steps take place.
`
`0. The port mapper is started on the server, normally when the server bootstraps.
`1. The mount daemon (mountd) is started on the server, after the port mapper. It
`creates a TCP end point and a UDP end point, and assigns ephemeral port num-
`ber to each. It then registers these port numbers with the port mapper.
`2. The mount command is executed on the client and it issues an RPC call to the
`port mapper on the server to obtain the port number of the server '5 mount dae-
`mon. Either TCP or UDP can be used for this client exchange with the port
`mapper, but UDP is normally used.
`
`3. The port mapper replies with the port number.
`
`4. The mount command issues an RPC call to the mount daemon to mount a file-
`system on the server. Again, either TCP or UDP can be used, but UDP is typi-
`cal. The server can now validate the client, using the client’s IP address and
`port number, to see if the server lets this client mount the Specified filesystem.
`5. The mount daemon replies with the file handle for the given filesystem.
`6. The mount command issues the mount system call on the client to associate the
`file handle returned in step 5 with a local mount point on the client. This file
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.12
`
`

`

`NFS Protocol
`
`471
`
`handle is stored in the NFS client code, and from this point on any references by
`user processes to files on that server's filesystem will use that file handle as the
`starting point.
`
`This implementation technique puts all the mount processing, other than the mount
`system call on the client, in user processes, instead of the kernel. The three programs
`we show—the mount command, the port mapper, and the mount daemon—are all user
`
`As an example, on our host sun (the NFS client) we execute
`sun # mount -t nfs bsdi: lusr lnfa/bsdi/usr
`
`This mounts the directory fusr on the host bsdi {the NFS server) as the local file-
`system lnfs/bsdi/usr. Figure 29.6 shows the result.
`.5 un client
`
`bsdi server
`
`
`
`
`Figure 29.6 Mounting the bsdi : lusr directory as Infs/bsdi/usr on the host sun.
`
`When we reference the file lnfs/bsdi/usr/rstevenslhello .c on the client sun
`
`we are really referencing the file /usr/rstevens/hello . c on the server bsdi.
`
`NFS Procedures
`
`The NFS server provides 15 procedures, which we now describe. (The numbers we use
`are not the same as the NFS procedure numbers, since we have grouped them according
`to functionality.) Although NFS was designed to work between different operating sys-
`tems, and not just Unix systems, some of the procedures provide Unix functionality that
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.13
`
`

`

`NFS: Network File System
`.——.__.—._._.—
`
`Chapter 29
`
`might not be supported by other operating systems (e.g., hard links, symbolic links,
`group owner, execute permission, etc). Chapter 4 of [Stevens 1992] contains additional
`information on the properties of Unix filesystems, some of which are assumed by NFS.
`
`1. GETATI'R. Return the attributes of a file: type of file (regular file, directory,
`etc), permissions, size of file, owner of file, last-access time, and so on.
`
`2. SE‘FA'ITR. fiet fireattrtbrrlm of a Bio. flr‘dy a subset ofEIie attributes can be set:
`permissions, owner, group owner, size, last-access time, and last-modification
`time.
`
`3. STATES. Return the status of a filesystem: amount of available space, optimal
`size for transfer, and so on. Used by the Unix at command, for example.
`4. LOOKUP. Lookup a file. This is the procedure called by the client each time a
`user process opens a file that’s on an NFS server. A file handle is returned,
`along with the attributes of the file.
`
`5. READ. Read from a file. The client specifies the file handle, starting byte off-
`set, and maximum number of bytes to read (up to 8192).
`
`6. WRITE. Write to a file. The client specifies the file handle, starting byte offset,
`number of bytes to write, and the data to write.
`
`NFS writes are required to be synchronous. The server cannot respond OK until
`it has successfully written the data (and any other file information that gets
`updated) to disk.
`
`7. CREATE. Create a file.
`
`8. REMOVE. Deletea file.
`
`9. RENAME. Rename a file.
`
`10. LINK. Make a hard link to a file. A hard link is a Unix concept whereby a
`given file on disk can have any number of directory entries (i.e., names, also
`called hard links) that point to the file.
`
`11. SYMLINK. Create a symbolic link to a file. A symbolic link is a file that con-
`tains the name of another file. Most operations that reference the symbolic link
`(e.g., Open) really reference the file pointed to by the symbolic link.
`
`12. READLINK. Read a symbolic link, that is, return the name of the file to which
`the symbolic link points.
`
`13. MKDIR. Create a directory.
`
`14. RMDIR. Delete a directory.
`
`15. READDIR. Read a directory. Used by the Unix ls command, for example.
`
`These procedure names actually begin with the prefix NFSPROC_, which we’ve
`dropped.
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.14
`
`

`

`NFS Protocol
`
`473
`
`UDP or TCP?
`
`NFS was originally written to use UDP, and that's what all vendors provide. Newer
`implementations, however, also support TCP. TCP support is provided for use on wide
`area networks, which are getting faster over time. NFS is no longer restricted to local
`area use.
`
`The network dynamics can change drastically when going from a LAN to a WAN.
`Iherormui-triptimeacanvary widelyandcongesfionismnretrequem. Thesecharac-
`teristics of WANs led to the algorithms we examined with TCP—slow start and congesv
`tion avoidance. Since UDP does not provide anything like these algorithms, either the
`same algorithms must be put into the NFS client and server or TCP should be used.
`
`NFS Over TCP
`
`[Macklem
`The Berkeley Net/2 implementation of NFS supports either UDP or TCP.
`1991] describes this implementation. Let’s look at the differences when TCP is used.
`
`1. When the server bootstraps, it starts an NFS server that does a passive open on
`TCP port 2049, waiting for client connection requests. This is usually in addi-
`tion to the normal NFS UDP server that waits for incoming datagrams to UDP
`port 2049.
`
`2. When the client mounts the server’s filesystem using TCP, it does an active open
`to TCP port 2049 on the server. This results in a TCP connection between the
`client and server for this filesystem.
`If the same client mounts another file-
`system on the same server, another TCP connection is created.
`
`3. Both the client and server set TCP’s keepalive option on their ends of the con-
`nection (Chapter 23). This lets either end detect if the other end crashes, or
`crashes and reboots.
`
`4. All applications on the client that use this server’s filesystem share the single
`TCP connection for this filesystem. For example, in Figure 29.6 if there were
`another directory named smith beneath Iusr on bsdi, references to files in
`lnfsfbsdir’usri'rstevens and fnfsfbsdifusrr‘smith would share the
`same TCP connection.
`
`5.
`
`If the client detects that the server has crashed, or crashed and rebooted (by
`receiving a TCP error of either "connection timed out" or ”connection reset by
`peer ”), it tries to reconnect to the server. The client does another active open to
`reestablish the TCP connection with the server for this filesystem. Any client
`requests that timed out on the previous connection are reissued on the new
`connection.
`
`6.
`
`If the client crashes, so do the applications that are running when it crashes.
`When the client reboots, it will probably,r remount the server '5 filesystem using
`TCP, resulting in another TCP connection to the server. The previous connection
`
`
`
`Petitioner Microsoft Corporation - Ex. 1017, p.15
`
`

`

`NFS: Network File System
`
`
`
`Chapter29
`
`
`
`between this client and server for this filesystem is half-open (the server thinks
`it’s still open), but since the server set the keepalive option, this half-open con-
`nection will be terminated when the next keepalive probe is sent by the server's
`TCP.
`
`Over time, additional vendors plan to support NFS over TCP.
`
`29.6 NFS Examples
`
`Let’s use tcpdump to see which NFS procedures are invoked by the client for typical file
`operations. When tcpdump detects a UDP datagrarn containing an RPC call (call equals
`0 in Figure 29.1) with a destination port of 2049, it decodes the datagram as an NFS
`request. Similarly if the UDP datagram is an RPC reply (reply equals 1 in Figure 29.2}
`with a source port of 2049, it decodes the datagram as an NFS reply.
`
`Simple Example: Reading a File
`
`Our first example just copies a file to the terminal using the cat(1) command, but the
`file is on an NFS server:
`
`sun t cat lute/hediluar/rstevans/hello.c
`main()
`
`copyfiktaiennbml
`
`printf("hello, wor1d\n"):
`
`On the host sun (the NFS client) the filesystem /nfs/bsdi /usr is really the lusr file-
`system on the host bsdi (the NFS server), as shown in Figure 29.6. The kernel on sun
`detects this when cat Opens the file, and uses NFS to access the file. Figure 29.7 shows
`the tcpdump output.
`
`0.0
`0.003587 (0.0036)
`
`sun.7aa6 > bsdi.nfs: 104 getattr
`bsdi.nfs > sun.7aa6: reply 0]: 96
`
`0.005390 (0.0013)
`0.009570 (0.0042)
`
`sun.7aa7 > bsdi.nfs: 116 lockup "rstevena"
`bsdi.nfs > sun.7aa7: reply ok 128
`
`0.011413 (0.0018)
`0.015512 (0.0041)
`
`sun.7aaB > bsdi.nfs: 116 lockup "hello.o"
`bsdi.nfs > sun.1aa8: reply ok 128
`
`0.018843 (0.0033)
`0.022377 (0.0035)
`
`sun.7aa9 > bsdi.nfs: 104 gotattr
`bsdi.nfs > sun.7a39: reply ok 96
`
`2
`
`3
`4
`
`5
`6
`
`7
`8
`
`9
`10
`
`0.027621 (0.0052)
`0.032170 (0.0045)
`
`sun.7aaa > bsdi.nfs: 116 read 1024 bytes E 9
`bsdi.nfs > sun.Taaa: reply 0k 140
`
`Figure 293ir NFS operations to read a file.
`
`‘I
`
`4
`
`i
`
`,
`5E
`
`'
`
`When tcpdump decodes an NFS request or reply, it prints the XID field for the client,
`instead of the port number. The XID field in lines 1 and 2 is 0x7aa6.
`
`I P
`
`Petitioner Microsoft Corporation - Ex. 1017, p.16
`
`

`

`
`NFS Examples
`475
`
`The filenarne lnfs/bsdilusr/rstevenslhello. c is processed by the open
`function in the client kernel one element at a time. When it reaches [nfs/bsdi/usr it
`
`detects that this is a mount point to an NFS mounted filesystem.
`In line 1 the client calls the GETATTR procedure to fetch the attributes of the
`server’s directory that the client has mounted (/usr). This RPC request contains 104
`bytes of data, exclusive of the [P and UDP headers. The reply in line 2 has a return
`value of OK and contains 96 bytes of data exclusive of the IP and UDP headers. We see
`in this figure that me minimum NFS message contains around 100 bytes of data.
`In line 3 the client calls the LOOKUP procedure for the file rstevens and receives
`an OK replyin line 4. The LOOKUP specifies the filename rstevens and the file han-
`dle that was saved by the kernel when the remote filesystern was mounted. The reply
`contains a new file handle that is used in the next step.
`In line 5 the client does a LOOKUP of hello . c using the file handle from line 4. It
`receives another file handle in line 6. This new file handle is w