Sldl Dllln Llbrl
`MHIIMWW
`WWII
`
`100000001982
`
` Il1ust1°a1
`Volumel
`The 1?fCatocols%%%
`The
`W. _.[_R5.1chard S,1:e.\./ens
`vens
`
`
`
`
`
`
`
`32112133:)NImcIwO31V\OISS3jOElcl/K3183.-1\r\"‘dOS|GClV
`
`Petitioner IBM — Ex. 1017, p. 1
`
`Petitioner IBM – Ex. 1017, p. 1
`
`

`
`UNIX is
`
`technology trademark of QOpen Company Ltd
`
`The publisher offers discounts on this book when ordered in quantity for special sales
`For more information please contact
`
`Coiporate
`
`Professional Publishing Group
`
`Addison-Wesley Publishing Company
`One Jacob Way
`Reading Massachusetts 01867
`
`Libraiy of Congress Cataloging-in-Publication
`
`Data
`
`Stevens
`
`Richard
`
`TCP/IP Illustrated the protocols/W Richard Stevens
`cm
`Includes bibliographical
`ISBN 0-201-63346-9
`
`Addison-Wesley
`references and index
`
`professional computing series
`
`1.TCP/IP Computer network protocol
`TK510535S74 1994
`
`Title II Series
`
`004.62-dc20
`
`Copyright
`
`1994 Addison Wesley Longman Inc
`
`All rights reserved No part of this publication may be reproduced stored in
`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
`Arnenca Published simultaneously in Canada
`
`Text printed on recycled and acid-free paper
`
`ISBN 0201633469
`161718192021 MA
`
`03020100
`
`16th Printing
`
`February 2000
`
`Petitioner IBM – Ex. 1017, p. 2
`
`

`
`29
`
`NFS Network FIle System
`
`IntroducUon
`
`In this chapter we describe NPS the Network File System another popular application
`file access for client applications The building block of NFS is
`that provides transparent
`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
`is on an NFS server and automatically generates the RPC
`the file being accessed
`calls to access the file
`in NFS is not in all the details on file access but in its use of the Internet
`Our interest
`protocols especially UDP
`
`that
`
`Sun Remote Procedure Call
`
`Most network programming is done by writing application programs that call system
`provided functions to perform specific network operations For example one function
`TCP active open another performs
`TCP passive open another sends data
`performs
`TCP connection
`another sets specific protocol options enable TCPs keepalive
`across
`timer and so on In Section L15 we mentioned that
`two popular sets of functions for
`network programming called APIs are sockets and TLL 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
`given client and server can communicate with each other
`determine if
`Unix client
`using sockets and TCP can communicate with mainframe server written
`written in
`in COBOL using some other API and TCP if both hosts are connected across
`network
`and both have
`TCP/IP implementation
`
`461
`
`Petitioner IBM – Ex. 1017, p. 3
`
`

`
`462
`
`NFS Network Pile System
`
`Typically the client sends commands to the server and the server sends
`to the client All the applications weve looked at so far Ping Traceroute
`mons and the clients and servers for the DNS TFTF BOOTP SNMP Telnet
`SMTP are built this way
`RPC Remote Procedure Call is
`different way of doing network programin
`client program is written that just calls functions in the server program This is ho
`appears to the programmer but the following steps actually taice pbce
`When the client calls the remote procedure its really calling
`local host thats generated by the RPC package This function is called tL
`stub The client stub packages
`the procedure arguments into
`network
`sage and sends this message to the server
`server stub on the server host receives
`the network message It
`takes the
`ments from the network message and calls the server procedure that
`cation programmer wrote
`When the server
`function returns it returns to the server stub which tak
`them into
`return values packages
`network message and sends the me
`back to the client stub
`The client stub takes the return values from the network message and
`the client application
`
`function
`
`the
`
`The network progranuning done by the stubs and the RPC library routines uses an
`such as sockets or TLI but the user applicationthe client program and the server
`cedures called by the cientnever deal with this API The client application just
`the server procedures and all
`the network programming details are hidden by the
`package the client stub and the server stub
`An RPC package provides numerous benefits
`
`involved
`
`The programming is easier since there is little or no network progranw
`The application programmer just writes
`client program
`server procedures that the client calls
`If an unreliable protocol such as UDP is used details like timeout and re
`mission are handled by the RPC package This simplifies the user applicati
`The RPC library handles any required data translation for the argument
`return values For example if
`the arguments consist of
`integers and flc
`point numbers the RPC package handles any differences in the way
`and floating point numbers are stored on the client and server This
`codmg clients and servers that can operate
`heterogeneous environments
`
`Details of RPC programming are provided in Chapter 18 of
`1990
`popular RPC packages are Sun RPC and the RPC package in the Open Software
`dations OSF Distributed Computing Environment DCE Our interest
`in RPC
`see what
`the procedure call and procedure return messages look like for the Sun
`package since its used by the Network File System which we describe in this cha
`of Sun RPC is defined in RFC 1057
`Version
`Microsystems 1988a
`
`Petitioner IBM – Ex. 1017, p. 4
`
`

`
`Section 292
`
`Sun RPC
`
`Sun Remote Procedure Call
`
`463
`
`Sun RPC comes in two flavors One version is built using the sockets API and works
`with TCP and UDR Another called TI-RPC for transport
`independent
`using the UI 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
`chaptet
`Iigre 294 httwthe férmafolart RPCprocedurtr call message when Ui is used
`
`is built
`
`IPheader
`
`20 bytes
`
`UDP header
`
`transaction ID X1D
`
`caflW
`
`RPCversion2
`
`program number
`
`version number
`
`procedure number
`
`common for
`all Sun RPC
`procedure aUs
`
`credentials
`
`up to 408 bytes
`
`upto 408 bytes
`
`depends on specific
`procedure being called
`
`procedure
`
`parameters
`
`Figure 29i Format of RP procedure alI message as UDP datagrarn
`The IF and UDP headers are the standard ones we showed earlier Figures 34 and 112
`What follows after the UDP header is defined by the RPC package
`ID XID is set by the client and returned by the server When the
`The transaction
`reply it compares the XID returned by the server with the XID of the
`client
`If they dont match the client discards the message and waits for the
`it sent
`request
`the UD
`next one from the server Each time the client
`new RPC it changes
`issues
`But
`previously sent RPC because it hasnt
`if the client
`retransmits
`received
`reply
`
`receives
`
`the ID does not change
`
`Petitioner IBM – Ex. 1017, p. 5
`
`

`
`464
`
`NFS Network File System
`
`identify
`
`reply The current RPC version is
`call and
`The call variable is
`for
`for
`three variables program number version number and procedure number
`next
`specific procedure on the server to be called
`The credentials
`In some instances nothing is sent here and
`identify the client
`other instances the numeric user ID and group IDs of the client are sent The server
`look at the credentials and determine if
`it will perform the request or not The
`used with Secure RPC which uses DES encryption Although the credentials and ye
`erre iable4ngth fieldx thelr length ieended iepart ef the field
`Following this are the procedure parameters The format of these depends on
`the remote procedure by the application How does the receiver
`definition of
`server stub know the size of the parameters Since UDP is being used the size of th
`UDP datagram minus the length of all the fields up through the verifier
`is the size
`the parameters When TCP is used instead of UDP there is no inherent length
`TCP is
`byte stream protocol without
`record boundaries
`To handle this
`41
`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
`tiple TCP segments if necessary The DNS uses
`similar technique see Exercise
`Figure 292 shows the format of an RPC reply This is sent by the server stub to the
`client stub when the remote procedure returns
`
`IP header
`
`20 bytes
`
`UDP header
`
`transaction ID XID
`
`reply 11
`
`status Oacceptedj
`
`venfler
`
`up to 408 bytes
`
`accept
`
`status
`
`success
`
`common for
`all Sun RPC
`
`procedure replies
`
`depends on
`specific procedure
`
`procedure
`results
`
`iv
`
`Figure 292 Format of RPC procedure reply message as
`
`tJDF datagani
`
`The XID in the reply is just copied from the XID in the call The reply is
`which we
`differentiates this message from call The status is
`if the call message was accept
`the RPC version number isnt
`The message can be rejected if
`or if the server cann
`authenticate the client The verzfier is used with secure RPC to identify the server
`
`Petitioner IBM – Ex. 1017, p. 6
`
`

`
`5ecOfl 294
`
`Port Mapper
`
`465
`
`status is
`
`The accept
`on success
`nonzero value can indicate an invalid version
`number or an invalid procedure number fo example As with the RPC call message if
`TCP is used instead of UDP
`4mbyte length field is sent between the TCP header and
`the XID
`
`293
`
`XDR Externa Data Representation
`
`lets
`
`XDR External Data Representation
`is the standard used to encode the values in the RPC
`call and reply messagesthe RPC header fields XID program number accept status
`etc the procedure parameters and the procedure results Having
`standard way of
`these values is what
`client on one system call
`encoding all
`procedure on
`sys
`XDR is defined
`RFC 1014
`tem with different architecture
`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
`alues we show XID call
`and 29
`see for example in Figures 29
`that all
`the mteger
`bytes in XDR
`program number etc are 4byte integers Indeed all
`integers occupy
`Other data types supported by XDR indude unsigned integers booleans floating point
`numbers fixed-length arrays variable-Length arrays and structures
`
`94 Port Mapper
`
`The RPC server programs containing the remote procedures use ephemeral ports not
`well-known ports This requires
`registrar of some farm that keeps track of which
`RPC programs are using which ephemeral ports In Sun RPC this registrar is called the
`port mapper
`
`and UDP port numbers
`in this name originates from the TI
`The term port
`Internee protocol suite Since TJRFC works over any transport layer and not
`and
`just TI
`IJDP the name of the port mapper in systems using TI-RPC 5VR4 and Solaris Z2 for exam
`pie has become rpcbind Well conbnue to use the more familiar name of port mapper
`well-known port UDP port 111 and
`Naturally the port mapper itself must have
`TCP port 111 The port mapper is also just an RPC server program It has
`program
`UDP port of 111
`number 100000
`TCP port of 111 and
`version number
`Servers register themselves with the port mapper using RPC calls and clients query the
`port mapper using RPC calls The port mapper provides four server procedures
`
`features of the
`
`program
`
`PMAPPROC SET Called by an RPC server on startup to register
`number version number and protocol with port number
`PMAPPROCJJNSET Called by server
`mapping
`PMAPPROC GETPORt Called by an RPC client on startup to obtain the port
`number for
`given program number version number and protocol
`
`to remove
`
`previously registered
`
`Petitioner IBM – Ex. 1017, p. 7
`
`

`
`466
`
`NPS Network File System
`
`Chapter 29
`
`PMAPPROCJUMP
`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
`
`it calls
`
`The port mapper must be started first normally when the system is boot
`IC end point and does
`passive open on TO port ilL
`strapped ft creates
`UDP end point and waits for UDP datagram to arrive for UDP
`It also creates
`port 111
`TCP end point and UDP end
`When the RPC server program starts it creates
`given RPC program
`point for each version of the program that it supports
`can support multiple versions The client specifies which version it wants when
`server procedure An ephemeral port number is bound to both end
`points ft doesnt matter whether the TCP port number is the same or different
`from the UD port number The server registers each program version proto
`ccl and port number by making
`remote procedure call
`to the port mappers
`PMAPPROC SET procedure
`calls the port mappers PMAP
`When the RPC client program starts it
`PROCGETPORT
`procedure to obtain the ephemeral port number for
`given
`program version and protocol
`The client sends an RPC call message to the port number returned in step
`IJDP is being used the client just sends UDP datagram containing an RPC call
`message Figure 29.1 to the servers UDP port numbet The server responds by
`UDP datagram containing an RPC reply message Figure 29.2 back to
`sending
`the client
`
`If
`
`If TCP is being used the client does an active open to the servers TCP port
`number and then sends an RPC call message across the connection
`The server
`responds with an RPC reply message across the connection
`
`The program rpcinfo8 prints out
`the port mappers current mappings It calls the
`port mappers PMAPPROCDUMP procedure Here is some typical output
`
`sun
`
`/uarf.to/rpcinfa
`program vera proto
`tp
`100005
`udp
`100005
`100005
`tcp
`100005
`udp
`
`port
`702
`inouratd
`699 mauntd
`702 mountd
`699 mauntd
`
`mmpsdaemanforNFS
`
`100003
`
`100021
`100021
`100021
`100021
`100021
`100021
`
`udp
`
`tcp
`udp
`tcp
`udp
`tcp
`udp
`
`2049
`
`nes
`
`NF$ itself
`
`NFS lock manager
`
`709
`
`1036
`
`721
`1039
`713
`1037
`
`nlockmgr
`nlockmgr
`nlockmgr
`nlockmgr
`nlockmgr
`nlockmgr
`
`Petitioner IBM – Ex. 1017, p. 8
`
`

`
`Section 295
`
`NFS Protocol
`
`467
`
`We see that some programs do support multiple versions and each combination of
`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
`
`295 NFS Protoco
`
`server This
`
`file that
`
`NFS provides transparent
`file access for clients to files and fflesystems on
`differs from FTP Chapter 27 which provides file transfer With FTP
`complete copy of
`the file is made NFS accesses only the portions of
`process references and
`goal of NFS is to make this access transparent This means that any client application
`that works with
`file should work with an NFS file without any program changes
`whatsoever
`NFS is
`clientserver application built using Sun RPC NFS clients access ifies on
`an NFS server by sending RPC requests to the server While this could be done using
`is the NFS client could be
`normal user processes
`that
`user process that makes
`explicit RPC calls to the server and the server could also be
`user process--NFS is nor
`mally not
`implemented this way for two reasons First accessing an NFS file must be
`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
`the NFS server were
`for efficiency
`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
`of NFS as documented
`In this section we look at version
`in RFC 1094
`better description of Sun RFC XDR and NFS is given in
`Microsystems 1988b1
`EX/Open 1991 Details on using and administering NFS are in
`19911 The speci
`of the NFS protocol were released in 1993 which we cover
`fications for version
`in Sec
`tion 291
`Figure 293 shows the typical arrangement
`There are many subtle points in this figure
`
`local
`
`transparent
`
`If
`
`of an NFS client and an NFS server
`
`It
`
`local
`
`file or an NFS file
`to the client whether
`is transparent
`its accessing
`The kernel determines this when the ifie is opened After the ifie is opened the
`kernel passes all
`ifies to the box labeled local
`file access
`and all references to an NFS file are passed to the NFS client box
`The MFS 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
`The NFS server
`requests as LTDP
`on port 2049
`datagrams
`Although the NES server could use an ephemeral port that it
`then registers with
`the port mapper UDP port 2049 is hardcoded into most implementations
`
`references to local
`
`receives client
`
`Petitioner IBM – Ex. 1017, p. 9
`
`

`
`468
`
`NF Network File System
`
`Chapter 29
`
`user
`
`process
`
`local
`acqs
`
`NFS
`IiIt
`
`Titio
`
`Lj
`
`client kernel
`
`local
`
`disk
`
`NFS
`
`Server
`
`/iJDPport
`2049
`
`Ioeal
`
`jffle access
`
`TCP/UDp
`
`serv kernel
`
`thsk
`
`Figure 293 Typical arrangement of NFS client and NFS server
`
`When the NFS server receives
`client request the requests are passed to its local
`file access routines which access
`local disk on the server
`It can take the NFS server
`while to handle
`clients request The local
`system is normally accessed which can take some time
`file-
`server does not want
`During this time the
`to block other client
`requests from being serviced
`dle this most NFS servers are mulhthreaded_that is there are really multiple
`To han
`NFS servers running inside the server kernel How this is handled depends on
`the operating system Since most Unix kernels are not multithreaded
`mon technique is to start multiple instances of
`com
`user process often called nfscl
`that performs
`single system call and remains inside the kernel as
`process
`
`kernel
`
`Similarly it can take the NFS client while to handle
`cess on the client host An RPC is issued to the server host and the
`request from user pro
`waited for To provide more concurrency to the user processes on the client host
`reply is
`that are using NFS there are normally multiple NFS clients running inside the
`client kernel Again the implenntation depends on the operating systemUnix systems often use
`
`technique similar to the NFS server
`process named hi od that performs
`user
`technique
`single system call and remains inside the
`kernel as
`kernel process
`
`Most Unix hosts can operate as either an NFS client an NFS server or both Most PC
`implementations MS-DOS only provide NFS client implementations Most IBM main
`frame implementali only provide NFS server
`
`functions
`
`Petitioner IBM – Ex. 1017, p. 10
`
`

`
`Section 295
`
`NPS Protocol
`
`469
`
`NFS really consists of more than just the NFS protocol Figure 29A shows the vari
`ous RPC programs normally used with NFS
`
`Application
`
`port mapper
`NPS
`mount
`
`lock manager
`status monitor
`
`Program
`
`Number of
`number jnumbersj procedures
`
`Version
`
`100000
`
`100005
`
`100005
`
`100021
`
`100024
`
`15
`
`19
`
`1.2
`
`Figure 29A Various RPC programs used with NFS
`
`L3
`The versions we show in this figure are the ones found on systems such as SunOS
`Newer implementations are providing newer versions of some of the programs Solaris 22
`of the mount
`and
`for example also supports versions
`of the port mappei and version
`daemon
`SVR4 also supports version
`of the port mapper
`
`The mount daemon is called by the NFS client host before the client can access
`filesystein on the servet We discuss this below
`The lock manager and status monitor allow clients to lock portions of
`that
`reside on an NFS server These two programs are independent
`the NFS protocol
`of
`because locking requires state on both the client and server and NFS itself
`is stateless on
`the server We say more about NFSs statelessness later Chapters
`10 and 11 of
`1991 document
`the procedures used by the lock manager and status monitor
`for file locking with NFS
`
`ifies
`
`File Handes
`
`client obtains
`
`in NFS is the file handle It
`is an opaque object used to reference
`fundamental concept
`ifie 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 ifie handle when access
`ing the file The client never looks at the contents of the file handleits contents only
`make sense to the server
`file on an NFS server the NFS
`Each time
`file that is really
`client process opens
`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
`is the NFS client code and
`Normal user processes never deal with file handLesit
`the NFS server code that pass them back arid forth In version
`of NFS
`file handle
`occupies 32 bytes although with version
`this changes from fixed-length field to
`variable-length field of up to 68 bytes
`
`fler
`
`Unix servers normally store the following information in the file handle the filesystem identi
`the major and minor device numbers of the filesystem the i-node number
`unique
`number within
`number
`number that changes each
`filesystem and an i-node generation
`time an i-node is reused for
`different file
`
`Petitioner IBM – Ex. 1017, p. 11
`
`

`
`470
`
`NFS Network File System
`
`Chapter 29
`
`Mount Protocol
`
`The client must use the NFS mount protocol
`to mount
`servers filesystem before the
`client can access ifies on that filesystem This is normally done when the client
`is boot
`strapped The end result is for the client
`to obtain
`ifie handle for the servers file
`system
`Figure 29.5 shows the sequence of steps that takes place when
`thounti$ command specting an NtS i1touñL
`
`Unix client
`
`issues
`
`user
`
`rocess
`
`po
`maperJ at start
`
`ter
`
`user process
`utd
`daemon
`
`user process
`
`unt
`command
`
`NFS
`
`get ort RPC
`
`uest
`
`7.RPCreywport
`
`mount RFC quest
`
`RPCreplyw filehande
`
`client kernel
`
`server kernel
`
`Ffgure 293 Mount protocol used by Unix
`
`unt command
`
`The following steps take place
`
`creates
`
`The port mapper is started on the server normally when the server bootstraps
`The mount daemon mountd is started on the server after the port mapper
`TCP end point and UDP end point and assigns ephemeral port num
`ber to each It then registers these port numbers with the port mapper
`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 servers mount dae
`mon Either TCP or UDP can be used for this client exchange with the port
`mapper but UDP is normally used
`The port mapper replies with the port number
`The mount command issues an RPC call to the mount daemon to mount
`system on the server Again either TCP or IJDP can be used but UDF is typi
`cal The server can now validate the client using the clients IP address and
`port number to see if the server lets this client mount the specified filesystem
`The mount daemon replies with the ifie handle for the given filesystem
`The mount command issues the mount system call on the client
`to associate the
`file handle returned in step with
`local mount point on the client This file
`
`It
`
`ifie
`
`Petitioner IBM – Ex. 1017, p. 12
`
`

`
`Section 295
`
`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 servers filesystem will use that ifie handle as the
`starting point
`
`than the mount
`the mount processing
`This implementation technique puts all
`other
`system call on the client
`in user processes instead of the kernel The three programs
`we showthe mount command the port mapper and the mount daemonare all user
`
`As an example on our host sun the NFS client we execute
`nfe bdi/uer
`/nfe/bdi/ur
`mount
`
`sun
`
`tthe NFS server as the local
`This mounts the directory /usr on the host bsdi
`system /nfs/bsdi/usr
`Figure 296 shows the result
`
`ffle
`
`sun client
`
`bSd3 server
`
`NFS mount
`
`he
`
`Figure 296 Mounting the bsdi usr directory as /nfs/bsdi
`
`uer on the hoft
`
`When we reference the file /nfsJbsdi/usr/rstevens/he11oc
`on the client sun
`on the server bsdi
`we are really referencing the ifie /usr/rstevens/hello
`
`NFS Procedures
`
`The NFS sewer provides 15 procedures which we now describe The numbers we use
`the same as the NFS procedure numbers since we have grouped them according
`are not
`to functionallty 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 IBM – Ex. 1017, p. 13
`
`

`
`472
`
`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
`information on the properties of Unix filesystems some of which are assumed by NFS
`
`19921 contains additional
`
`of
`
`GETATrR Return the attributes of
`file type of file regular file directory
`etc permissions size of file owner of file Iastaccess time and so on
`SETATTR Setthattrftmtes
`a1ft Only lbset of the attributes can be set
`permissions owner group owner size last-access
`time and lastmodificatjori
`time
`
`STATFS Return the status of
`ifiesystem amount of available space optimal
`size for transfer and so on Used by the Unix
`command for example
`LOOKUB Lookup
`file This is the procedure called by the client each time
`file thats on an NFS server
`user process opens
`ifie handle is returned
`along with the attributes of the file
`READ Read from file The client specifies the file handle starting byte off
`set and maximum number of bytes to read up to 8192
`WRiTE Write to
`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 synthrcrnous The server cannot respond OK until
`it has successfully written the data and any other
`file information that gets
`updated to disk
`
`file
`
`CREATE Create
`REMOVE Delete
`RENAME Rename
`
`file
`
`file
`
`file
`
`file
`
`ifie
`
`is return the name of the file to which
`
`10 LINK Make
`hard link to
`hard link is Unix concept whereby
`given file on disk can have any number of directory entries i.e names also
`called hard links that point to the file
`SYMLNK Create
`symbolic link to
`file that con
`symbolic link is
`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
`symbolic link that
`the symbolic link points
`13 MKDIR Create
`
`directory
`
`14 RMDIR Delete
`
`directory
`
`15 READDIR Read
`
`directory Used by the Unix
`
`command for example
`
`These procedure
`dropped
`
`names actually begin with the prefix NFSPROC which weve
`
`Petitioner IBM – Ex. 1017, p. 14
`
`

`
`Section 295
`
`UDP0rTCP
`
`NFS Protocol
`
`473
`
`NFS was originally written to use UDP and thats what all vendors provide Newer
`implementations however also support TCP TCP support
`provided for use on wide
`time NFS is no longer restricted to local
`area networks which are getting faster over
`area use
`The network dynamics can change drastically when going from LAN to WAN
`The undirip timeb
`vxy widely ansi congestion is more frequent These charac
`teristics of WANs led to the algorithms we examined with TCPslow start and conges
`Since UDP does not provide anything like these algorithms either
`tion avoidance
`same algorithms must be put into the NFS client and sewer or TCP should be used
`
`the
`
`NFS Over TCP
`
`The Berkeley Net/2 implementation of NFS supports either UDP or TCP
`Lets look at the differences when TCP is used
`1991 describes this implementation
`
`When the sewer bootstraps it starts an NFS sewer that does
`passive open on
`TCF 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 UDF
`port 2049
`When the client mounts the sewers filesystem using TCF it does an active open
`TCP connection between the
`to TCP port 2049 on the server This results in
`client and server
`the same client mounts another
`for this filesystem If
`system on the same server another TCP connection is created
`
`ifie
`
`Both the client and server set TCFs keepalive option on their ends of the con
`nection Chapter 23 This lets either end detect
`the other end crashes or
`crashes and reboots
`
`if
`
`on the client
`that use this servers filesystem share the single
`All applications
`TCP connection for this filesysteni For example in Figure 296 if
`there were
`another directory named smith beneath /usr on bsdi references to files in
`and /nfs/bsth/usr/sinith
`/nfs/bsdifusr/rstevens
`would share the
`same TCP connection
`
`Il
`
`the server has crashed or crashed and rebooted by
`the client detects that
`TCP error of either connection timed out or connection reset by
`receiving
`peer it tries to reconnect
`to the server The client does another active open to
`reestablish the TCP connection with the sewer for this filesystem Any client
`timed out on the previous connection are reissued on the new
`requests that
`connection
`
`If
`
`the client crashes so do the applications that are running when it crashes
`When the client reboots it will probably remount the servers ifiesystem using
`TCP. resulting in another TCP connetion to the server The previous connection
`
`Petitioner IBM – Ex. 1017, p. 15
`
`

`
`474
`
`NFS Network File System
`
`Chapter 29
`
`between this client and server for this fflesystem is half-open the server thinks
`its 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 servers
`TCP
`
`Over time additional vendors plan to support NFS over TCP
`
`296 NFS Examples
`
`Lets use tcpdump to see which NFS procedures are invoked by the client
`for typical file
`operations When tcpdump detects UDP datagram containing an RPC call call equals
`destination port of 2049 it decodes the datagrarn as an NFS
`in Figure 29.1 with
`the UDP datagram is an RPC reply reply equals
`in Figure 292
`request Similarly if
`with source port of 2049 it decodes the datagram as an NFS reply
`
`Smpe Exampe Readng
`
`FRa
`
`Our first example just copies
`ifie is on an NFS server
`
`file to the terminal using the cat1 command but the
`
`c.t
`
`/nfsfbi/ur/ratevene/hel1o.c
`
`capyfile to terminal
`
`aun
`main
`
`prlntf hello world\n
`
`On the host sun the NFS client the filesystem /nfs/bsdi/usr
`is really the /usr 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 tcpduinp output
`
`0.0
`8.003587
`
`0.0036
`
`0.005390 0.0018
`0.009570 00042
`0.011413 0.0018
`0.0041
`0.015512
`
`0.0033
`0.018843
`0.022377 0.0035
`
`0.027621
`0.032170
`
`10
`
`0.8052
`0.0045
`
`sun.7aaS
`bsth.nfe
`
`sun.laa7
`bsdi.nfs
`
`sun7aa8
`bsdi.nfs
`
`sun.7aa9
`bsdi.nfe
`
`sun7aaa
`bsdi.nf
`
`bsdi.nfs 104 getattr
`sun.7aa6
`reply ok 96
`
`bsdinfs 116 lookup rstevCne
`sun.laa7
`reply ok 128
`lookup hel1o
`bdinfs 116
`sunlaaB reply ok 128
`
`bsdinfs 104 getattr
`sun.7ae9
`reply ok
`96
`
`bsdinfa 116 read 1024 bytes
`sun.aea reply ok 140
`
`Figtare 29.7 NFS operations
`
`to read
`
`file
`
`When tcpdump decodes an NFS request or reply it prints the Xli field for the client
`instead of the port number The ID field in lines
`is Ox7aa6
`and
`
`Petitioner IBM – Ex. 1017, p. 16
`
`

`
`Section 296
`
`NFS Examples
`
`475
`
`is processed by the open
`The filename /nfs/bsdi/usr/rstevens/he1loc
`time When it
`reaches /nfs/bsdi/usr
`function in the client kernel one element at
`detects that this is mount point to an NFS mounted filesystexn
`the client calls the GETATFR procedure to fetch the attributes of
`In line
`servers directory that the client has mounted /usr This RPC request contains 104
`the IF and TJDP headers
`The reply in line
`has
`return
`bytes of data exclusive of
`value of OK and contains 96 bytes of data exclusive of the IP and UDP headers We see
`this figze tbat the müum NFS message contains around 100 bytes of data
`the client calls the LOOKUP procedure for the file rstevens and receives
`In line
`The LOOKUF specifies the filename rstevens and the file han
`an OK reply in line
`die that was saved by the kernel when the remote ifiesystem was mounted The reply
`new file handle that is used in the next step
`contains
`LOOKUP of hello using the file handle from line
`the client does
`This new file handle is what
`the client uses in lines
`file handle in line
`receives another
`We see that
`to reference the file /nfs/bsdi/usr/rstevenslhelloc
`and
`client does LOOKIJP for each component of the pathname that is being opened
`the client does another GETA1TR followed by READ in line
`The client
`In line
`but
`less After subtracting the sizes of
`asks for 1024 bytes starting at offset
`the RPC fields and the other values returned by the READ procedure 38 bytes of data
`are returned in line 10 This is indeed the size of the ifie hello
`these NFS requests and
`In this example the