user to be granted, based upon the user's authentic identity. Access control is not provided in RPC and must be supplied by the application. Several different authentication protocols are supported in RPC. A field in the RPC header indicates what protocol is being used. The RPC protocol provides the fields neces- sary for a client to identify itself to a service and vice versa. The call message has two authentication fields, the credentials and verifier. The reply message has one authentication field, the response verifier. The RPC protocol specification defines all three fields as the following opaque type: enum auth_flavor { UTH NONE = 0, AUTH UNIX = 1, AUTH SHORT = 2, AUTH DES = 3, AUTH KERB = 4 /* and more to be defined * / struct opaque_auth { auth_flavor flavor; RPC Programming Here opaque_auth structure is an auth_flavor enumeration followed by bytes that are opaque to the RPC protocol implementation. The interpretation and semantics of the data contained within the authentication fields is specified by individual, independent authentication protocol specifications. When authentication param- eters are rejected, the response message contains information stating why they were rejected. In scenarios where the caller is not aware of the authentication parameters and the server does not want to perform any specific authentication, then AUTH NULL (0) can be used. In this case, the auth_flavor value of the RPC message credentials and verifier, and response verifier correspond to null authentication. The caller of a remote procedure may want to identify itself as it is identified on a trusted UNIX system. In this case AUTH_UNIX (1) is used. 27.4 Defining the Protocol The easiest way to define and generate the protocol is to use a protocol complier such as rpcgen. For the protocol you must identify the name of the service procedures, and data types of parameters and return arguments. The protocol compiler reads a definition and automatically generates client and server stubs. The rpcgen uses its own language (RPC 