gtpa2m2o | Application Programming |
An Internet server application must conform to one of the process models defined by the Internet daemon:
The WAIT process model is for an Internet server application that is an iterative or single-thread program. The Internet daemon starts the Internet server application as a child process using the tpf_fork function and does not start any more occurrences of the Internet server application until the one that is running ends.
For TCP servers, the Internet daemon creates and monitors the listener socket. When a remote client connects, information about the socket that is associated with this client (the connected socket) is passed to the child process. The child process communicates with the remote client over the connected socket. If the child process ends and does not close the connected socket, the TPF system closes the connected socket automatically.
For UDP servers, the Internet daemon creates and monitors the socket. When a message from a remote client is received, the socket is passed to the child process, allowing the child process to exchange data with the remote client.
The NOWAIT process model is for an Internet server application that is a concurrent or multi-thread program. The Internet daemon starts the Internet server application as a child process using the tpf_fork function and continues to start more occurrences of the Internet server application until a predefined limit is reached. When the limit is reached, no more occurrences are started until an occurrence that was previously started ends.
For TCP servers, the Internet daemon creates and monitors the listener socket. When a remote client connects, information about the socket that is associated with this client (the connected socket) is passed to the child process. The child process communicates with the remote client over the connected socket. If the child process ends and does not close the connected socket, the TPF system closes the connected socket automatically. If you do not want the socket to be closed when the child process ends, the child process must issue an fcntl function with the O_TPF_NODDCLOSE option on the socket. You must do this when the child process passes the socket to another ECB (for example, using the activate_on_receipt function.)
For UDP servers, the Internet daemon creates and monitors the socket. When a message from a remote client is received, the socket is passed to the child process, allowing the child process to exchange data with the remote client. The Internet daemon will not create another child process until the previous child process ends, or until the previous child process sends a SIGUSR1 signal to the Internet daemon. If child processes do not send SIGUSR1 signals, the NOWAIT model becomes single threaded and has the same characteristics as the WAIT model. If the UDP server application is bound to all local IP addresses and more than one local IP address exists, the child process should not send the SIGUSR1 signal until after the process has sent all its data to the remote client. If a SIGUSR1 signal is sent before all the data is sent, the wrong local IP address can be placed in the packets sent to the remote client, causing that data to be discarded.
The AOR process model is for an Internet server application that is a concurrent or multithread program. The AOR process model can be used only for TCP servers, not UDP. The Internet daemon creates and monitors the listener socket. 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.
The DAEMON process model is for an Internet server application that is started and monitored by the Internet daemon. The Internet daemon starts the Internet server application as a child process by using the tpf_fork function and does not start any more occurrences of the Internet server application until the one that is running ends. The Internet daemon does not create or monitor any sockets for this process model.
The NOLISTEN process model is for an Internet server application that the Internet daemon only starts. The Internet daemon does not create or monitor any sockets, nor does it monitor the server application.
The RPC process model is for a remote procedure call (RPC) server application that the Internet daemon only starts. The Internet daemon does not create or monitor any sockets, nor does it monitor the server application.
Because these process models provide different levels of control, the overhead of system resource can be affected. The AOR process model has the potential to use system resources more effectively than the WAIT and NOWAIT process models. The AOR process models uses the activate_on_receipt or activate_on_receipt_with_length function to create the entry control block (ECB) for the Internet server application only after data is received on a connected socket, whereas the WAIT and NOWAIT process models use the tpf_fork function to create an ECB for immediate processing, which requires the Internet server application to request data and then wait for the data to arrive.
For the NOWAIT process model, use the MAXPROC parameter in the ZINET ADD or ZINET ALTER command to limit the number of occurrences of an Internet server application that the Internet daemon starts. For the AOR process model, there is no throttling control, so the Internet daemon can potentially start more occurrences of the Internet server application until system resources are depleted. See TPF Operations for more information about the ZINET ADD and ZINET ALTER commands.
In general, a ported Internet server application uses the WAIT or NOWAIT process model and an Internet server application designed specifically for TPF architecture uses the AOR process model.
When the Internet daemon is running, there is one long-running ECB for the Internet daemon monitor program and one long-running ECB for each server application that the Internet daemon is monitoring. Some E-type loader operations are not completed until all old ECBs exit in the system. When the Internet daemon detects that the system activation number has changed, the Internet daemon recycles itself. A new instance of the Internet daemon is immediately created in new ECBs, and the old Internet daemon ECBs exit when all their child processes end. When the Internet daemon recycles, the effect on the server application and sockets is based on the process model:
When you enter the ZINET STOP command to stop a server application, the actions that are taken are based on the process model:
See TPF Operations for more information about the ZINET STOP and ZSOCK commands.
The following sections describe the processing flow for each process model based on the transport protocol (Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)).
In a TCP environment, if you specify the NOWAIT process model, the Internet daemon starts the Internet server application as a child process using the tpf_fork function and then immediately processes the next request. Figure 26 shows the relationship of the parent and child processes and an overview of the logic flow of process control and socket APIs.
Figure 26. TCP and the NOWAIT Process Model. After starting the Internet server application, the Internet daemon processes the next request from the Internet.
In a TCP environment, if you specify the WAIT process model, the Internet daemon starts the Internet server application as a child process using the tpf_fork function and does not process the next request (that is, the Internet daemon waits) until the Internet server application ends and the TPF system sends a SIGCHLD signal. Figure 27 shows the relationship of the parent and child processes and an overview of the logic flow of process control and socket APIs.
Figure 27. TCP and the WAIT Process Model. After starting the Internet server application (child process), the Internet daemon (parent process) does not continue processing until the Internet server application ends and the TPF system signals to the parent process that the child process has ended.
In a TCP environment, if you specify the AOR process model, the Internet server application is started as a new entry control block (ECB) when there is data for it by an activate_on_receipt function call. Meanwhile, the Internet daemon continues to process requests from the Internet. Figure 28 shows the relationship of the Internet daemon listener and an Internet server application using the AOR process model and an overview of the logic flow of socket APIs.
Figure 28. TCP and the AOR Process Model. After starting the Internet server application, the Internet daemon accepts the next request from the Internet.
In a TCP environment, if you specify the DAEMON process model, the Internet daemon starts the Internet server application as a child process by using the tpf_fork function and does not process the next request (that is, the Internet daemon waits) until the Internet server application ends and the TPF system sends a SIGCHLD signal back to the Internet daemon. Figure 29 shows the relationship of the parent and child processes and an overview of the logic flow of process control and socket APIs.
Figure 29. TCP and the DAEMON Process Model. After starting the Internet server application (child process), the Internet daemon (parent process) does not continue processing until the Internet server application ends and the TPF system signals to the parent process that the child process has ended.
In a UDP environment, if you specify the NOWAIT process model, the Internet daemon starts the Internet server application as a child process using the tpf_fork function and then waits until the child process sends a SIGUSR1 signal before continuing its processing. Figure 30 shows the relationship of the parent and child processes and an overview of the logic flow of process control and socket APIs.
Figure 30. UDP and the NOWAIT Process Model. After starting the Internet server application (child process), the Internet daemon (parent process) waits until the child process sends a SIGUSR1 signal before continuing its processing.
In a UDP environment, if you specify the WAIT process model, the Internet daemon starts the Internet server application as a child process using the tpf_fork function and does not process the next request (that is, the Internet daemon waits) until the Internet server application ends and the TPF system sends a SIGCHLD signal. Figure 31 shows the relationship of the parent and child processes and an overview of the logic flow of process control and socket APIs.
Figure 31. UDP and the WAIT Process Model. The Internet daemon (parent process) does not continue processing until the Internet server application (child process) ends and the TPF system signals to the parent process that the child process has ended.
The following sections describe the interface between the Internet daemon and an Internet server application for the process model based on the transport protocol (TCP or UDP).
The Internet server application is started using the tpf_fork function and must be a C or C++ main program.
When the Internet server application receives control, the following data is in the entry control block (ECB):
The Internet daemon has accepted a socket connection, and the socket descriptor passed in EBW000 is for the connected socket.
Although it is not necessary for the Internet server application to explicitly reference the associated process block, the following inheritance properties, as defined by UNIX, are passed to the Internet server application:
The Internet daemon does not accept another connection or data until the ECB for the Internet server application ends.
The Internet server application must close the socket from which the request was received.
See TPF Operations for more information about the ZINET ADD command.
The Internet server application is started using the tpf_fork function and must be a C or C++ main program.
When the Internet server application receives control, the following data is in the entry control block (ECB):
The Internet daemon has accepted a socket connection, and the socket descriptor is passed in EBW000 for the connected socket.
Although it is not necessary for the Internet server application to explicitly reference the associated process block, the following inheritance properties, as defined by UNIX, are passed to the Internet server application:
The Internet server application must close the socket from which the request was received.
See TPF Operations for more information about the ZINET ADD command.
The Internet server application is started using the tpf_fork function and must be a C or C++ main program.
When the Internet server application receives control, the following data is in the entry control block (ECB):
Although it is not necessary for the Internet server application to explicitly reference the associated process block, the following inheritance properties, as defined by UNIX, are passed to the Internet server application:
The Internet daemon does not accept another connection or data until the ECB for the Internet server application ends.
The Internet server application must not close the socket from which the request was received.
See TPF Operations for more information about the ZINET ADD command.
The Internet server application is started using the tpf_fork function and must be a C or C++ main program.
When the Internet server application receives control, the following data is in the entry control block (ECB):
Although it is not necessary for the Internet server application to explicitly reference the associated process block, the following inheritance properties, as defined by UNIX, are passed to the Internet server application:
The Internet server application must not close the socket from which the request was received.
See TPF Operations for more information about the ZINET ADD command.
The Internet daemon uses the activate_on_receipt function to start the Internet server application.
When the Internet server application receives control, most of the data in the ECB is provided by the TPF system. However, the Internet daemon obtained the user parameter string from the IDCF that was initialized by the PARM parameter in the ZINET ADD command. This parameter string is the data at EBW004-011.
See TPF Operations for more information about the ZINET ADD command. See the description of the activate_on_receipt function in TPF Transmission Control Protocol/Internet Protocol for the layout of the data in the ECB.
The Internet daemon issues the activate_on_receipt function for a connected socket.
There are no inheritance properties associated with this model because the Internet server application is started as a new ECB rather than a child process.
Use the ZINET ADD command to add an Internet server application to the IDCF. See TPF Transmission Control Protocol/Internet Protocol and TPF Operations for more information about the ZINET ADD command and adding entries to the IDCF.