Transport Selection

RPC services are supported on both circuit-oriented and datagram transports. The selection of the transport depends on the requirements of the application.

Choose a datagram transport if the application has all of the following characteristics:

• Calls to the procedures do not change the state of the procedure or of associated data.

• The size of both the arguments and results is smaller than the transport packet size.

• The server is required to handle hundreds of clients. A datagram server does not keep any state data on clients, so it can potentially handle many clients. A circuit-oriented server keeps state data on each open client connection, so the number of clients is limited by the host resources.

Choose a circuit-oriented transport if the application has any of the following characteristics:

• The application can tolerate or justify the higher cost of connection setup compared to datagram transports.

• Calls to the procedures can change the state of the procedure or of associated data.

• The size of either the arguments or the results exceeds the maximum size of a datagram packet.

Name-to-Address Translation

Each transport has an associated set of routines that translate between universal network addresses (string representations of transport addresses) and the local address representation. These universal addresses are passed around within the RPC system (for example, between rpcbind and a client). A runtime linkable library that contains the name-to-address translation routines is associated with each transport. Table 2-7 shows the main translation routines.

For more details on these routines, see the netdir(3NSL) man page. Note that the netconfig structure in each case provides the context for name-to-address translations.

Table 2-7 Name-to-Address Translation Routines