Iterative versus Concurrent Servers

A server process may respond to incoming connections in two different ways. The first response pattern looks like this:

1. The server receives the incoming connection.
2. The server handles the connection.
3. The server closes the connection.
4. The server returns to listening on its well-known port.

A server that operates like this is called an iterative server. When an iterative server is handling a request, other connections to that port are blocked. The incoming connections must be handled one after another. For example, a system in which the telnet server is set up as an iterative server can handle only one incoming telnet connection at a time.

In the context of IBM, a (TP) transaction program is an application that executes business transactions on IBM mainframe systems, specifically within IBM's transaction processing subsystems, such as CICS (Customer Information Control System) or IMS (Information Management System). These subsystems are designed to manage high volumes of transactions efficiently and securely in a mainframe environment. A transaction program performs one or more specific tasks related to a business process, such as updating a customer's account balance, processing an order, or managing inventory. These programs are designed to be modular, meaning they can be called upon by other programs, user interfaces, or APIs to perform their specific tasks as part of a larger business process. Transaction programs in IBM mainframe systems typically have the following characteristics:

1. Designed to handle high volumes of concurrent users and transactions efficiently.
2. Built to ensure data integrity, even in the case of hardware or software failures.
3. Able to recover from errors and provide reliable processing of transactions.
4. Developed using programming languages such as COBOL, PL/I, or Java, which are commonly used in mainframe environments.
5. Utilize database systems like DB2, IMS DB, or VSAM to store and manage data.
6. Often integrated with other transaction programs or systems to support complex business processes.

In summary, a transaction program in the IBM context refers to an application designed to execute business transactions on IBM mainframe systems, specifically within transaction processing subsystems like CICS or IMS. These programs are built to manage high volumes of transactions, ensure data integrity, and provide reliable processing in a mainframe environment.

In the Iterative model, the Listener and Server portions of the application coexist in the same CICS or IMS (TP) transaction program and run as part of the same CICS task. The server application, therefore, holds the socket until all application processing has completed. This means that after a client Transaction Program starts a server TP, another client TP cannot access the Listener or the server transaction program until the first client is finished.

The second type of response pattern looks like this:

1. The server receives the incoming connection.
2. The server calls fork() to split itself into two processes, a parent and a child.
3. The child process handles the connection, while the parent returns to listen on the original port.
4. When the child process is finished with the connection, it terminates.

A server that operates like this is called a concurrent server. A concurrent server is always available for incoming connections. For example, a system in which the telnet server is set up as a concurrent server can handle multiple telnet connections, each of which is managed by a different child of the listening server process.

We use the term iterative server to describe a server implementation that processes one request at a time, and the term concurrent server to describe a server that handles multiple requests at one time. Although most concurrent servers achieve apparent concurrency, we will see that a concurrent implementation may not be required- it depends on the application protocol. In particular, if a server performs small amounts of processing relative to the amount of I/O it performs, it may be possible to implement the server as a single process that uses asynchronous I/O to allow simultaneous use of multiple communication channels. From the perspective of the client, the server appears to communicate with multiple clients concurrently. The point is:
Question: Does the server handle multiple requests concurrently?
The term concurrent server refers to whether the server handles multiple requests concurrently, not to whether the underlying implementation uses multiple concurrent processes.

In general, concurrent servers are more difficult to design and build, and the resulting code is more complex and difficult to modify. Most programmers choose concurrent server implementations. However, because iterative servers cause unnecessary delays in distributed applications^[1] and can become a performance bottleneck that affects many client applications. We can summarize:
Iterative server implementations, which are easier to build and understand, may result in poor performance because they make clients wait for service or threads to become available. In contrast, concurrent server implementations, which are more difficult to design and build, yield better performance.

[1]distributed application: A distributed application consists of one or more local or remote clients that communicate with one or more servers on several machines linked through a network. With this type of application, business operations can be conducted from any geographical location.