Open System Services Porting Guide (G06.24+, H06.03+)

OSS Porting Considerations
Open System Services Porting Guide—520573-006
6-24
Careful Programming With Static Servers
For example, the World Wide Web (WWW) server program httpd is implemented in
UNIX systems as a dynamic server. Each time a new request is received by the WWW
server, a new process is created by the fork() function to handle the incoming
request. When the handling of the request is complete, the process terminates. The
WWW server handles multiple requests in parallel by creating a new process to handle
each request to completion.
In the OSS environment, the iTP Secure WebServer program httpd is implemented
as a set of static servers. That is, the iTP Secure WebServer creates a number of
static servers, which read their requests from a queue file written by the iTP Secure
WebServer, which, in turn, listens for incoming requests from the network. Each static
server waits for another request—after it has handled a current request. This strategy
enables requests to be processed without the additional overhead of process creation
and termination. (Refer to the iTP Secure WebServer System Administrator’s Guide for
more information about the iTP Secure WebServer; refer to the httpd(8) reference
page online on systems that have the iTP Secure WebServer installed for more
information about httpd in the OSS environment.)
A demon (or daemon) is a system process, usually a server process, started at
system initialization. Examples of demons are an application process that is always
running or a process that executes under control of the timing subsystem. Demons are
often listener processes, handling remote requests and supporting user-level functions
in a network; they can start static servers and dynamic servers.
The Guardian LISTNER process and the UNIX inetd process are both examples of
demon processes. The OSS version of inetd is not a true demon, because it is not
started at system initialization; OSS inetd is a static super server, as described under
Guardian LISTNER Versus UNIX and OSS inetd on page 6-25.
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,