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

9
Figure 7. OPEN opcode reply
The reply from the server is shown in Figure 7. The state identifier on line 13 represents this client’s
file open. It is returned by the server as part of the reply to the OPEN opcode. This identifier is used to
associate state with this instance of this file open.
Delegation
Normally, an NFS server is responsible for managing file locks and file data across a network. The
centralized responsibility is necessary when multiple client machines are accessing a remotely served
file.
However, if only one client is writing to a file or multiple clients are only reading a file, then
management of that file’s locks and data can be delegated (management of locks and data for that
file are performed locally on that client or clients). Delegation results in performance gains because
network traffic between the NFS server and NFS client necessary to manage that file is avoided.
Because clients take on the responsibility for managing a file’s locks and data, the server must verify
that the client is still up and reachable. The NFSv4 server verifies the client’s availability by sending
RPC requests to the NFSv4 client’s callback daemon (nfs4cbd). The server uses the callback and
callback_ident fields that were sent in the SETCLIENTID request (see Figure 3) to determine where the
client’s nfs4cbd is listening.
When a delegation must be revoked, the nfs4cbd is responsible for returning to the server any locking
or file data managed on the client. For example, a delegation must be revoked if a local application
attempts to write to a file while the NFS client is writing to the same file, otherwise there will be data
corruption.
However, until ONCplus version B.11.31.03, NFSv4 servers on HP-UX 11i v3 support delegation
with the caveat that no local file access should occur on that file.