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

Table Of Contents
OSS Porting Considerations
Open System Services Porting Guide520573-006
6-23
Porting Servers and Demons
The Guardian procedures that map OSS pathnames and Guardian filenames,
FILENAME_TO_PATHNAME_ and PATHNAME_TO_FILENAME_, support symbolic
links. Detailed information on using these Guardian procedures is located in the
Guardian Procedure Calls Reference Manual.
Porting Servers and Demons
A common performance enhancement during porting is to convert servers that create
many short-lived child processes (which handle one request each) into servers that
create a few long-lived child processes (perhaps one per processor) that handle a
stream of requests one at a time. With additional logic for load-leveling and fault
recovery, the ported application can take advantage of NonStop system fundamentals.
In the client and server model, communication takes the form of request and reply
pairs, which are initiated by the client and serviced by the server. For example, servers
support Internet services such as FTP, TELNET, SMTP, and so on. This subsection
focuses on how using static servers and demon processes can improve system
performance in the OSS environment.
A dynamic server is a server process created by an application or super server to
handle a new request as it comes in. Dynamic servers work well when the request rate
is low or the time required to provide the service is relatively long, such as with FTP.
A dynamic server exists only as long as it is needed. It is created to handle each new
request, service the request, then quit; many dynamic servers can be created and run
simultaneously. Dynamic servers are commonly used in UNIX networking
environments for handling many incoming requests.
A static server is a server process started from the shell. A static server typically
performs one function. In a UNIX environment, static servers often start dynamic
servers.
A static server creates a socket, binds that socket to a specific address (including a
communications port), and listens to that address for connection requests for a specific
service. When a connection request arrives, the static server can create a new process
as a dynamic server to perform the service either by calling a fork() function
followed by one of the exec functions or by calling the tdm_spawn() or
tdm_spawnp() function to perform the fork and exec operations in one step. The
new process can be started on the same or a different processor.
A static server can be a server process started by another server. A static server exists
continuously (while the system is running) and handles requests as it receives them,
usually by interacting with a queue file. It does not terminate after handling a request.
You should use static servers when the request rate from clients is high and the time to
service the request is short (relative to the time to process calls to the fork() function
and the exec set of functions). If the program you are porting to the OSS environment
uses many calls to fork() and the exec set and you do not use static servers, you
will have a slowing of system performance.