Programming with Remote Procedure Calls (RPC)

Network selection

Network selection is a simple way by which users and applications may dynamically select transports, according to both their preferences and the available transports. It is based on two mechanisms, the netconfig(4bnu) database, which lists the transports available on the host and identifies them by type, and the optional environment variable NETPATH, which allows the user to specify preferences among the transports available in /etc/netconfig that are acceptable to the application. For more details about network selection, see ``Network selection'' and the getnetconfig(3N) manual page.

NOTE: To create a service for a particular transport, an application must interface to RPC at a level below the top level, that is, the level composed of clnt_create and its associated routines on the rpc_clnt_create(3rpc) manual page. Only then can it specify the types of transports that it prefers. See ``Remote Procedure Call programming'' for details about the various RPC levels.

The /etc/netconfig file contains several lines, each of which corresponds to an available transport (see netconfig(4bnu)). These are some possible entries:

   # The Network Configuration File.
   #
   # Each entry is of the form:
   #
   # network_id semantics flags protofamily protoname device nametoaddr_libs
   #
   ticlts tpi_clts v loopback - /dev/ticlts /usr/lib/straddr.so
   ticots tpi_cots v loopback - /dev/ticots /usr/lib/straddr.so
   ticotsord tpi_cots_ord v loopback - /dev/ticotsord /usr/lib/straddr.so
   starlan tpi_cots v osinet - /dev/starlan /usr/lib/straddr.so

   starlang tpi_clts v osinet - /dev/starlang /usr/lib/straddr.so
   tcp tpi_cots_ord v inet tcp /dev/tcp /usr/lib/tcpip.so

   udp tpi_clts v inet udp /dev/udp /usr/lib/tcpip.so

   icmp tpi_raw - inet icmp /dev/icmp /usr/lib/tcpip.so
   rawip tpi_raw - inet - /dev/rawip /usr/lib/tcpip.so

The following are a few points about /etc/netconfig, and the applications interface to it:

Each entry contains an identifier (the first field) which gives the network identifier by which the transport is commonly known.
Each entry also contains a flag or set of flags (the third field) that identifies it by type -- the v flag, for example, identifies any transport that is ``visible.''
The last field names a run-time linkable module that contains the name-to-address translation routines associated with the transport. (See ``Name-to-address translation'').
The loopback transports are required for registering services with rpcbind. They are local transports, available only to local clients and servers, and hence are more secure than other transports.

The format of NETPATH is an ordered list of network identifiers separated by colons (:) (for example: udp:tcp:starlan). By setting NETPATH, the user can specify the order in which the application should try the various networks. If NETPATH is not set, the system defaults to all visible transports specified in /etc/netconfig, in the order they appear.

NOTE: Applications can choose to ignore a user's NETPATH.

RPC divides selectable transports into the following types:

``netpath'': Choose from those transports that have been specified in the NETPATH environment variable. If NETPATH is not set, the system defaults to all visible transports specified in /etc/netconfig, in the order they appear.
``'': (null) -- same as selecting ``netpath''.
``visible'': Choose those transports that have the visible flag (`v') set in their /etc/netconfig entries.
``circuit_v'': Same as ``visible'', but restricted to connection-oriented transports.
``datagram_v'': Same as ``visible'', but restricted to connectionless transports.
``circuit_n'': Choose from whatever is defined in NETPATH, but restrict to connection-oriented transports.
``datagram_n'': Choose from whatever is defined in NETPATH, but restrict to connectionless transports.
``udp'': (For backwards compatibility) -- specifies Internet User Datagram Protocol (UDP).
``tcp'': (For backwards compatibility) -- specifies Internet Transmission Control Protocol (TCP).

When a transport-dependent application begins execution, it begins by calling the setnetconfig, getnetconfig, and endnetconfig routines, using them to search /etc/netconfig for a transport of appropriate type. This information is then stored in local data structures of type struct netconfig and is available for later use. setnetconfig, getnetconfig, and endnetconfig are described on the getnetconfig(3N) manual page; the Network Selection Administrative file /etc/netconfig is described on the netconfig(4bnu) manual page.

Taken together, these mechanisms allow a fine degree of control over network selection: a user can specify a preferred transport, and if it is reasonable, applications will use it. In cases where the specified transport is inappropriate (as, for example, when a remote server does not support a specified transport) the application should automatically try others with the right characteristics.