RPC和NFS

参考:http://eduunix.ccut.edu.cn/index2/html/linux/OReilly.SUSE.Linux.Jul.2006/059610183X/suselinux-CHP-7-SECT-3.html

上面的链接基于suse,说的不错

Function

The RPC system is intended as functions to be integrated into network programs rather than as a command-line operations. An RPC, as part of a program running on a client computer, sends a message to a remote server. This message includes a command and required parameters. The command being executed must be a program residing on the remote computer. It does not need to be locally available.

NFS Procedures

The Network File System is the best known example of RPC usage. Under NFS, files are held on a remote server but appear to be available locally. Local programs want to access a file and do so by calling a procedure on the remote server, rather than accessing a local process.

Execution

RPC is implemented by compiling a client program and a server program on each computer. Calls to these programs are implemented by a series of functions available in the "C" programming language. The RPC libraries need to be included in the header of the program and then RPC functions like rpc_call() can be used within the "C" program.

RPC Protocol Overview

The Remote Procedure Call (RPC) protocol, documented in RFC 1831, is designed to augment IP in a different way than TCP. While TCP is targeted at the transfer of large data streams (such as a file download), RPC is designed for network programming, allowing a program to make a subroutine call on a remote machine. The most important application of RPC is the NFS file sharing protocol.

The key features of RPC are:

Request-reply. RPC is a request-reply protocol, and can exhibit the "ping-pong" behavior typical of such protocols. This is not fundamental to RPC's design (since multiple requests can be outstanding, and replys can come in any order), but most programs will issue a single RPC request, and then block awaiting a reply.
UDP or TCP transport. RPC actually operates over UDP or TCP. RPC/UDP is a connection-less, stateless protocol. RPC/TCP is slower, but provides a reliable, stateful connection.
Standardized data representation. RPC encodes its data using the eXternal Data Representation (XDR) protocol, documented in RFC 1832, which standardizes the format of integers, floating point numbers, and strings, permitting different types of computers to enhance information seamlessly.
Authentication. RPC provides support for authenticating the calling program on one machine to the target subroutine on the other. Authentication can operate in several different modes. During NFS operations, authentication usually takes the form of relaying UNIX user and group IDs to the file server for permission checking.

RPC Service Rendezvous

Both TCP and UDP rely on well-known port numbers to perform service rendezvous. For example, TCP TELNET service is available on port 21, FTP on port 23, SMTP on port 25, and so on. Connecting to TCP and UDP services simply requires connecting to the right port number.

RPC introduces another step in this process, to divorce services from being tied to a given port number. It does so using a special RPC service called PORTMAP or RPCBIND. These binding protocols, documented in RFC 1833 and often referred to as the portmapper, are unique among RPC services since they have an assigned port of their own (port 111). Other RPC services, running on any port number, can register themselves using an RPC call to port 111. The portmapper offers other RPC calls to permit service lookup.

The most important consequence of this design is that the portmapper must be the first RPC program started, and must remain in constant operation.

NFS Protocol Overview

The Network File System (NFS), developed by Sun Microsystems, is the de facto standard for file sharing among UN*X hosts. NFS Version 3 is documented in RFC 1813. The Mount Protocol is closely related.

NFS is implemented using the RPC Protocol, designed to support remote procedure calls. All NFS operations are implemented as RPC procedures. A summary of NFS procedures is show below:

Procedure 0:  NULL - Do nothing

Procedure 1:  GETATTR - Get file attributes

Procedure 2:  SETATTR - Set file attributes

Procedure 3:  LOOKUP - Lookup filename

Procedure 4:  ACCESS - Check Access Permission

Procedure 5:  READLINK - Read from symbolic link

Procedure 6:  READ - Read From file

Procedure 7:  WRITE - Write to file

Procedure 8:  CREATE - Create a file

Procedure 9:  MKDIR - Create a directory

Procedure 10: SYMLINK - Create a symbolic link

Procedure 11: MKNOD - Create a special device

Procedure 12: REMOVE - Remove a File

Procedure 13: RMDIR - Remove a Directory

Procedure 14: RENAME - Rename a File or Directory

Procedure 15: LINK - Create Link to an object

Procedure 16: READDIR - Read From Directory

Procedure 17: READDIRPLUS - Extended read from directory

Procedure 18: FSSTAT - Get dynamic file system information

Procedure 19: FSINFO - Get static file system Information

Procedure 20: PATHCONF - Retrieve POSIX information

Procedure 21: COMMIT - Commit cached data on a server to stable storage

NFS is a stateless protocol. This means that the file server stores no per-client information, and there are no NFS "connections". For example, NFS has no operation to open a file, since this would require the server to store state information (that a file is open; what its file descriptor is; the next byte to read; etc). Instead, NFS supports a Lookup procedure, which converts a filename into a file handle. This file handle is an unique, immutable identifier, usually an i-node number, or disk block address. NFS does have a Read procedure, but the client must specify a file handle and starting offset for every call to Read. Two identical calls to Read will yield the exact same results. If the client wants to read further in the file, it must call Read with a larger offset.

Of course, this is seldom seen by the end user. Most operating systems provide system calls to open files, and read from them sequentially. The client's operating system must maintain the required state information, and translate system calls into stateless NFS operations.

NFS Performance

NFS performance is closely related to RPC performance. Since RPC is a request-reply protocol, it exhibits very poor performance over wide area networks. NFS performs best on fast LANs.