listen(1M)listen(1M)NAMElisten - network listener port monitor
SYNOPSIS
/usr/lib/saf/listen [ -m devstem ] net_spec
DESCRIPTION
The listen port monitor ``listens'' to a network for service requests,
accepts requests when they arrive, and invokes servers in response to
those service requests. The network listener process may be used with
any connection-oriented network (more precisely, with any connection-
oriented transport provider) that conforms to the Transport Interface
(TLI) specification.
The listener internally generates a pathname for the minor device for
each connection; it is this pathname that is used in the utmp entry for a
service, if one is created. By default, this pathname is the
concatenation of the prefix /dev/netspec with the decimal representation
of the minor device number. When the -m devstem option is specified, the
listener will use devstem as the prefix for the pathname. In either
case, the representation of the minor device number will be at least two
digits (for example, 05 or 27), but will be longer when necessary to
accommodate minor device numbers larger than 99.
SERVER INVOCATION
When a connection indication is received, the listener creates a new
transport endpoint and accepts the connection on that endpoint. Before
giving the file descriptor for this new connection to the server, any
designated STREAMS modules are pushed and the configuration script is
executed, if one exists. This file descriptor is appropriate for use
with either TLI (see especially t_sync(3N)) or the sockets interface
library.
By default, a new instance of the server is invoked for each connection.
When the server is invoked, file descriptor 0 refers to the transport
endpoint, and is open for reading and writing. File descriptors 1 and 2
are copies of file descriptor 0; no other file descriptors are open. The
service is invoked either with the user ID under which the service was
registered with the listener, or as an authenticated ID if an
authentication scheme was specified instead. If both an ID and
authentication scheme are specified for the service in the listener's
administrative file, the listener does the authentication, but then runs
the service under the specified ID.
Alternatively, a service may be registered so that the listener will pass
connections to a standing server process through a FIFO or a named
STREAM, instead of invoking the server anew for each connection. In this
case, the connection is passed in the form of a file descriptor that
refers to the new transport endpoint. Before the file descriptor is sent
to the server, the listener interprets any configuration script
registered for that service using doconfig(3N), although doconfig is
invoked with both the NORUN and NOASSIGN flags. The server receives the
Page 1
listen(1M)listen(1M)
file descriptor for the connection in a strrecvfd structure via an
I_RECVFD ioctl(2).
For more details about the listener and its administration, see
nlsadmin(1M). Note that neither the 'nlsadmin' command and it's
associated manual page have been ported, but should appear in the next
IRIX release. The command gives some documentation as to the features of
the network listener.
FILES
/etc/saf/pmtag/*
SEE ALSOsac(1M), doconfig(3N), streamio(7)NOTES
When passing a connection to a standing server, the user and group IDs
contained in the strrecvfd structure will be those for the listener; the
user name under which the service was registered with the listener or the
authenticated ID is not reflected in these IDs.
When operating multiple instances of the listener on a single transport
provider, there is a potential race condition in the binding of addresses
during initialization of the listeners if any of their services have
dynamically assigned addresses. This condition would appear as an
inability of the listener to bind a static-address service to its
otherwise valid address, and would result from a dynamic-address service
having been bound to that address by a different instance of the
listener.
Page 2
