Because rpcbind is responsible for mapping network services to their addresses, its address must be well known. The name-to-address translation routines for any particular transport should know and reserve a particular address for rpcbind.
In the Internet domain, this problem is solved by always assigning rpcbind the port number 111. Unfortunately, this simple solution is not acceptable on all transports.
rpcbind begins each session by registering its location on each of the transports supported by the host. rpcbind is the only network service that must have such a well-known address. The address must be well-known for a given transport because rpcbind is responsible for registering the addresses of other network services and making those addresses available to network clients. Thus, services make their addresses available to clients by registering their addresses with their host's rpcbind daemon. Thereafter, the addresses of the services are available to rpcinfo(C) and to programs using library routines specified in rpcbind(NS).
RPC-based servers typically get mapped to network addresses at run time, and then they register with rpcbind, and neither they nor their clients can make any assumptions about what those network addresses will be.
rpcbind is started by the system or RPC administrator. Both server programs and client programs call rpcbind.
As part of its initialization, a server program calls its host's rpcbind daemon to register itself in the host's registered-address map. Whereas server programs call rpcbind to update address maps, clients call them to query those maps. To find a remote program's address, a client sends an RPC call message to a server machine's rpcbind daemon; if the remote program is on the server, the daemon returns the relevant address in an RPC reply message. The client program can then send RPC call messages to that address.
The rpcbind protocol (for details, see ``rpcbind protocol'') provides a procedure, RPCBPROC_CALLIT, with which rpcbind can assist a client in making a remote procedure call. A client program passes the target procedure's program number, version number, procedure number (for a discussion of these numbers, see ``Remote Procedure Call programming'') and arguments in an RPC call message. rpcbind then looks up the target procedure's address in the address map and sends an RPC call message, including the arguments received from the client, to the target procedure.
When the target procedure returns results, RPCBPROC_CALLIT passes them on to the client program. It also returns the target procedure's address so the client can later call it directly.
The RPC library provides an interface to all rpcbind procedures. Some of the RPC library procedures also call rpcbind automatically for client and server programs.