Process models

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 z/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 z/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 z/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 AOA process model offers asynchronous control for TCP servers by using the activate_on_accept function. The Internet Daemon issues the first activate_on_accept function call. When the first remote client connects, your TCP server application is activated in a new ECB. Your server application must issue the next activate_on_accept function call. The Internet Daemon continues to monitor the server application.
  • The AOA2 process model offers asynchronous control for TCP servers by using the activate_on_accept function. The Internet Daemon issues all activate_on_accept function calls. When the remote client connects, the Internet Daemon activates your TCP server application in a new ECB. The Internet Daemon monitors the server application and listener socket until the server is stopped or the system is not in the right state.
  • The SSL process model offers asynchronous control for SSL servers by using the activate_on_accept function. The Internet Daemon issues all activate_on_accept function calls. When the remote SSL client connects, the Internet Daemon activates your SSL server application in a new ECB. The Internet Daemon monitors the SSL server application, listener socket, and CTX until the server is stopped, SSL daemons are stopped, or the system is not in the right state.
  • 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 process model offers 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 z/TPF program.