|
|
Client programs need a way to find server programs; that is, they need a way to look up the addresses of server programs. Network transport services do not themselves provide such a service; they merely provide process-to-process message transfer across a network. A message is sent to a transport-specific network address. A network address is a logical communications channel; by waiting on a network address, a process receives messages from the network.
RPC, being transport independent, makes no assumptions about the structure of a network address. It deals with universal addresses, specified only as null-terminated strings of characters. RPC translates universal addresses into local transport addresses by using routines specific to each transport provider. For more details on these routines, see the netdir(3N) manual page.
Operating systems provide (differing) mechanisms by which a process can wait on a network address, that is, synchronize its activity with arriving messages. Thus, messages are not sent across networks to receiving processes, but rather to the transport address at which receiving processes pick them up. Transport addresses are valuable because they allow message receivers to be specified in a way that is independent of the conventions of the receiving operating system. The rpcbind protocol defines a network service that provides a standard way for clients to look up the transport address of any remote program supported by a server. Because the rpcbind protocol can be implemented for any transport, it provides a single solution to a general problem that works for all clients, all servers and all networks.