Administering the listen port monitor

What listen does

listen performs functions common to all port monitors:

it initializes and monitors listen ports
it identifies and authenticates users
it invokes the service associated with a port in response to requests

The listener differs from previous listeners in several ways:

it allows private addresses for services
passes connections (file descriptors) to standing servers
supports socket-based services
supports Remote Procedure Call (RPC) based services and dynamic addressing

Private addresses for services

Each listen service may have a transport address in addition to its service code (svctag). This private address is included in the port monitor's administrative file. The inclusion of private addresses for services allows a single listen process to monitor multiple addresses. This functionality might be useful for purposes such as balancing loads and making services, such as a name server, work more efficiently. The number of addresses on which the listener can listen is determined by the number of file descriptors available to the process.

Passing connections to standing servers

By default, a new instance of a service is invoked for each connection. Beginning with UNIX System V Release 4, the listener has the ability to pass an incoming connection (file descriptor) to a standing server, eliminating the fork and exec overhead for each call (see nlsadmin(1M)). This feature is useful for server processes that need to maintain state information.

NOTE: A standing server is a server process or service that runs continuously and accepts connections through a FIFO or a named STREAM instead of being fork-ed and exec-ed.

Socket-based services

The listener supports services that use sockets as their interface to the transport provider. Socket-based services are registered with the listener in the same way TLI-based services are, using the SAF's administrative commands. listen supports STREAMS; sockets is implemented as a STREAMS module and a library.

A socket-based service:

may or may not be an RPC service
may have a statically or dynamically assigned address or no private address
may be invoked on each connection or may be a standing server to which new connections are passed by a FIFO or a named STREAM.

RPC-based services and dynamic addressing

Dynamic addressing is most useful with RPC. RPC transport addresses may be either specified or dynamically assigned. In either case, the listener tells rpcbind what the address is and monitors it for incoming connections.

In the case of a dynamically assigned address, listen asks the transport provider to select a transport address each time the listener begins listening on behalf of the service.

When service addresses are dynamically assigned, the assigned address is written to the listener's log file.