IMPLICATIONS OF STATELESSNESS                                                                                                 Back To Home

Stateful File Services:

The mechanism is as follows:

1. Client opens a file.
2. Server fetches information about the file from its disk, stores it in memory, and gives the client a connection identifier unique to the client and the open file.
3. Identifier is used for subsequent access until the session ends.
4. Server must reclaim the main-memory used by clients who are no longer active

Advantages:

1. Fewer disk accesses.
2. Stateful server knows is a file was opened for sequential access and can thus read ahead the next blocks.

Stateless File Server:

• Avoids state information by making each request self contained
• Each request identifies the file and the position in the file
• No need to establish and terminate a connection by open and close operations

The Network File System protocols was intended to be as stateless as possible. That is, a server should not need to maintain any protocol state information about any of its clients in order to function correctly. Stateless servers have the advantage of being able to recover gracefully in the case of event/system failure. With stateless servers, a client need only retry a request until the server responds; it does not even need to know that the server has crashed, or the network temporarily went down. The client of a state aware server, on the other hand, needs to either detect a server failure and rebuild the server's state when it comes back up, or cause client operations to fail.

This has the following implication: RPC requests must fully describe the operation to be performed. For example, the write operation must specify the file to use (via the file handle), the starting location, and the number of bytes to be written. This is much different that a write statement on a local file system.

The stateless protocol design was chosen because it greatly simplified the design of NFS. Servers do not have to worry abut transactions or journaling. One advantage of this is that it allows a server to reboot and have little affect on a client. The client will just sit there waiting for the server to come back up. When it does it issues the request and continues on. Of course, users or applications are stuck waiting on the I/O to complete.

In terms of complexity during implementation, it simplifies the server implementation because the server does not store much information. However, it adds a bit of complexity in the protocol to be able to write very simple servers that do not require fancy crash recovery.

Next: Usefulness of RPC and XDR

Sources:

http://userpages.umbc.edu/~jack/ifsm498d/nfs.html
http://www.bopac2.comp.brad.ac.uk/~aqdavis/NFS/nfs.htm#mount protocol