Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)

Careful Programming With Static Servers
When dynamic servers are used, a programmer can be careless about how memory is deallocated
and files are closed after a request is handled because dynamic servers are terminated after
handling the request. Because static servers are not terminated after a request is handled, more
careful accounting for resource use by the server program is required.
If memory is not released after its use (creating memory leaks) a process can grow to be very large.
If files are not closed after their use, the number of files kept open by a process will increase until
some limit is hit, and the process might abort. You should be careful when working with static
servers so they are serially reusable in the OSS environment. Be sure to include statements in your
programs to deallocate memory and close files.
Static Servers and Load Balancing
Using the NonStop architecture, you can set up many static servers. For example, for eight
processors, you can have eight different static servers, distributing requests across different
processors. These servers can all be processing requests in parallel, without interfering with each
other. A super server handles all requests and passes requests to the other servers. When necessary,
the NonStop operating system can activate a static server process in an additional processor, thus
spreading the load throughout the system.
Guardian LISTNER Versus UNIX and OSS inetd
A listener server acts as a handler process when network activity is detected on ports under its
domain of management. This way, one handler process, also called a super server, can handle
multiple ports, dramatically reducing the system resources for creating new processes and for file
operations. With one handler process, the specific needs of individual services can be met in
logical, consistent ways. The Guardian LISTNER process and the OSS inetd process are both
listener and static servers.
In the Guardian environment, LISTNER is the super server and listener process for the application
servers provided by HP, such as the TELNET server. LISTNER invokes the appropriate Guardian
server as connection requests for services are received on well-known TCP ports (in the default
configuration).
To use the LISTNER process, you must configure the PORTCONF file and start the LISTNER process.
The PORTCONF file defines the servers to be invoked when a request comes in from another system
on the Internet. Once started, LISTNER reads the SERVICES file to resolve the services configured
in the PORTCONF file. LISTNER checks that the service name and corresponding port are valid.
In the OSS environment, inetd is a server process that listens for network activity. inetd is
considered an Internet super server, because it is able to handle requests for multiple Internet
services. When started, inetd listens for connections on certain Internet ports. When a connection
request is received, inetd decides to which service the request corresponds and invokes a server
program to service the request. Like the LISTNER process in the Guardian environments, inetd
provides server functions for application servers, such as TELNET.
The inetd process reads the /etc/inetd.config file, which defines the servers to be invoked
when a request comes in from the network. This file contains a table with port-to-service assignments,
used to service requests that start servers. Using /etc/inetd.config, inetd invokes the
appropriate server (with a fork() call and a call to one of the exec set of functions) for the
connection request. Refer to the inetd(8) reference page either online or in the Open System
Services Shell and Utilities Reference Manual for information on the command that starts inetd
and for the format of entries in the /etc/inetd.config file.
inetd simplifies the interface of a server program that it starts, because it duplicates its socket
descriptors for an incoming request as file descriptors 0, 1, and 2 before the server application is
processed by an exec function call. This action allows the server application to use stdin,
stdout, and stderr in function calls to perform the requested service.
Porting Servers and Demons 105