gtpa2m2i | Application Programming |
The Internet daemon consists of two major components:
- The Internet daemon monitor, which is responsible for starting
and stopping the Internet daemon listeners for Internet server applications
and for error recovery when an Internet daemon listener fails.
- An Internet daemon listener, which monitors the Internet server
applications and, with some process models, creates and monitors a socket for
the Internet server application.
The following process models define the interface to the Internet
daemon:
- The WAIT process model
offers synchronous control by using the tpf_fork function to
create a child process. When the entry control block (ECB) associated
with the child process ends, the TPF system sends a SIGCHLD signal to the
Internet daemon (parent process). After the Internet daemon issues the
tpf_fork function, the Internet daemon waits for the child process
to end before activating another child process. In other words, only
one child process can be active at a time.
For TCP servers, the child process is created when a remote client connects
and the Internet daemon accepts the socket connection. For UDP servers,
the child process is created when a message is received on the UDP
socket. Information about the socket is passed to the child process,
enabling the child process to communicate with the remote client over the
socket.
- The NOWAIT process model
offers synchronous control by using the tpf_fork function to
create a child process. When the ECB associated with the child process
ends, the TPF system sends a SIGCHLD signal to the Internet daemon (parent
process). Multiple child processes can be concurrently active up to a
user-defined limit. You can define this limit by specifying the MAXPROC
parameter on the ZINET ADD or ZINET ALTER command. See TPF Operations for more information about the ZINET ADD
and ZINET ALTER commands.
For TCP servers, the child process is created when a remote client connects
and the Internet daemon accepts the socket connection. For UDP servers,
the child process is created when a message is received on the UDP
socket. Information about the socket is passed to the child process,
enabling the child process to communicate with the remote client over the
socket.
For UDP servers, after the Internet daemon creates a child process, the
next child process is not activated until the previous child process ends or
the previous child process sends a SIGUSR1 signal to the Internet daemon
indicating that the child process is no longer using the socket. If
child processes do not issue any SIGUSR1 signals, the NOWAIT process model has
the same characteristics as the WAIT process model for UDP servers.
- The AOR process model
offers asynchronous control for TCP servers by using the
activate_on_receipt or activate_on_receipt_with_length
function. When a remote client connects, the Internet daemon issues an
activate_on_receipt or activate_on_receipt_with_length
function to pass control of the new socket to your TCP server application when
the first message is received from the remote client. After the
Internet daemon issues the activate_on_receipt or
activate_on_receipt_with_length function, the Internet daemon
continues processing.
- The NOLISTEN and RPC process models
offer no control because a swisc_create function is used to create
an ECB for the specified Internet server application. The Internet
daemon is used only to activate the server for these models. The
Internet daemon does not create or monitor any sockets, nor does it monitor
the server application.
- The DAEMON process model
is similar to the NOLISTEN process model, but uses the tpf_fork
function.
The DAEMON process model does not create or monitor any sockets, but the
Internet daemon does monitor the server application.
All Internet server applications handled by the Internet daemon follow a
defined process model; these process models are described in more detail
in Internet Server Application Considerations and Considerations for Using the Internet Daemon to Start a TPF Program.
The data for all Internet server applications processed by the Internet
daemon is maintained in the Internet daemon configuration file (IDCF).
See TPF Transmission Control Protocol/Internet
Protocol for more information about the IDCF.