Introducing Network File System Version 4 on HP-UX 11i v3

5
No mount or locking protocols
In Figure 1, there are no mount protocol messages; mounting is handled by the PUTROOTFH opcode,
which is part of NFSv4. Similarly, there is no separate file locking protocol. Locking is handled by the
NFSv4 opcodes LOCK, LOCKU, and LOCKT. These opcodes are discussed in the “File Locking as
part of the NFSv4 protocol” section.
NFSv4 as a stateful protocol
Previous NFS protocols were stateless in the sense that the NFS server maintained no information or
state about its clients. For example, previous NFS protocols define no open or close operations; NFS
clients perform lookup operations on directories and files, and NFS servers respond with the
appropriate directory or file handle. A file operation such as a read() would manifest itself as an
NFS request to read a range of bytes from a particular file handle. Although opaque to the NFS
client, this file handle often represents the disk-based data associated with a file.
NFSv4, however, is stateful; the NFSv4 server maintains information about its clients, the files they
hold open, and locks. For example, a second COMPOUND procedure (shown in Figure 3) was also
generated as part of the mount command. This COMPOUND procedure consists solely of the
SETCLIENTID opcode.
Figure 3. SETCLIENTID opcode request
The SETCLIENTID opcode is creates a data structure used to manage state associated with this client
on the server. The SETCLIENTID opcode consists of the fields client, callback, and callback_ident. The
callback fields shown in lines 9 through 14 in Figure 3 are associated with this client identifier on the
server and are used to manage delegations. Delegations are covered in a subsequent section.
When the server receives a SETCLIENTID opcode, the server assigns a unique identifier to the client
and returns that identifier to the client in its reply to the SETCLIENTID opcode. This reply is shown in
Figure 4.