上面的链接基于suse,说的不错
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.
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.
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.
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:
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.
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 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.
原文：http://www.cnblogs.com/jjkv3/p/3850563.html