One of the most crucial aspects of TCPIP communications in WebSphere Message Broker (WMB) is management of TCPIP connections. TCPIP nodes were first introduced in WMB V6.1 and are used in broker's communication with the TCPIP applications. Depending on the nature of your requirement, a broker can be used as a TCPIP client or a TCPIP server. The TCPIP node communication with other TCPIP applications is based on general client server connectivity principles as listed below:
- The server application listens on a local port (on the computer that is running the application) for requests for connections to be made by a client application.
- The client application requests a connection from the server port, which the server then accepts. The client application keeps making client connections until the minimum number of connections is reached.
- When the server accepts the request, a port is created on the client computer and is connected to the server port.
- A socket is created on both ends of the connection, and the details of the connection are encapsulated by the socket.
- The server port remains available to listen for further connection requests until the maximum number of connections is reached.
TCPIP nodes in WMB establish connections with the TCPIP applications by deriving their connections from the pool that is handled at the execution group level. Each execution group process contains a connection manager, which makes the connections out of its own pool of connections. All the TCPIP server nodes (TCPIPServerInput node, TCPIPServerOutput node and TCPIPServerReceive node) that use the same port must be in the same execution group. The TCPIP input (TCPIPServerInput node, TCPIPClientInput node) and TCPIP receive nodes (TCPIPServerReceive node, TCPIPClientReceive node) are used to retrieve data, and the TCPIP output nodes (TCPIPServerOutput node, TCPIPClientOutput node) are used to send data.
Typically, there are two connection states within the connection manager of an execution group:
Each TCPIP connection has one input stream and one output stream and each of these streams has the two connection states highlighted above.
By reserving a connection stream, you can restrict access to the connection. When this connection is in reserved state, no other node can access the stream without specifying the ID of the connection. This connection ID is an internal identifier used by broker to uniquely identify the connection. While the stream is in the reserved state, no node (including the node that put the stream into the reserved state) can access it. The only nodes that can access the stream must have the connection ID, which is written to the outgoing local environment when the data is passed down the message flow.
For example: The ID location property of the TCPIPServerOutput and TCPIPServerReceive nodes can be:
When a connection is reserved, ownership of the connection is given to a current thread for processing.
The reserve mechanism provides the following options:
- Leave unchanged: Default value indicating stream is left available. For example, when you are moving data from an input stream to a file
- Reserve: To connect a series of nodes to give complex processing on a stream in an ordered, controlled, synchronous sequence. For example, asynchronous request and reply
- Release: For all nodes, the connection for the streams is released
- Reserve and release at the end of the flow: to reserve a connection and to ensure that the connection's stream is released when the message flow has finished processing (including any error conditions that might occur)
These parameters of reserve mechanism can be set at the node level as shown in Figure 1 below:
Figure 1 (click image to enlarge)
Some of the TCPIP connection properties can be configured via ESQL compute node. For example, you can set a TCPIP port number using the following ESQL:
set InputLocalEnvironment.Destination.TCPIP.Output.Port = <your port#>
Some TCPIP connection properties can also be configured on the TCPIP configurable service both for the client or server. The default configurable service may be configured using the command mqsichangeproperties or a new configurable service may be created using the command mqsicreateconfigurableservice.
The configurable connection parameters on the default configurable services for TCPIP server and TCPIP client nodes are shown in the Figure 2 (TCPIP server) and Figure 3 (TCPIP client) below:
Figure 2 (click image to enlarge)
So, if you would like to configure any of the parameters listed in the screenshot above, you can do so via MB Explorer - Brokers > Configurable Services > TCPIPServer/Default or using the command mqsichangeproperties. For example, to change the MaximumConnections property, please issue:
mqsichangeproperties <brokerName> -c TCPIPServer -o MaximumConnections -v <integer_value>
Figure 3 (click image to enlarge)
You can also display these properties using the command mqsireportproperties as shown below:
mqsireportproperties V8BK -c TCPIPClient -o AllReportableEntityNames -r
The execution group uses the configurable service or the properties defined on the node to determine which attributes are used for the socket connection. When a connection is opened by the connection pool within the connection manager, it is then sent to the respective node, which then routes a message containing details of the connection (without any data) to the Open terminal of the node. The connection pool can be configured using the attributes such as Minimumconnections, MaximumConnections in addition to the properties on the node discussed above. Also, connection expiry and port number on which the connection is established may also be configured using the configurable services. There are also socket related configurable properties such as SO_KEEPALIVE (socket checks that it is still connected after a specified time), SO_LINGER_TIMEOUT_SEC (delay value in seconds for closing a socket) that can be configured for the connection. You can find a detailed explanation about these parameters in the "Configurable services properties" section of the WebSphere Message Broker information center.
Once you have configured these parameters, you can design/create scenarios based on reservation/availability of connections. Some common examples include the following:
Synchronous/Asynchronous request/reply scenarios: You can configure Synchronous and Asynchronous request/reply scenarios, so the connection can be reserved after sending the request and released once the reply has been received.
Configuring a server socket so that connections expire after a specified time: If you want to configure a server socket so that connections are established and they expire after a specified time or after the message is processed.
In order to see the state of a TCPIP connection, you can run commands such as netstat -an. The following list shows the common connection states:
- LISTEN or LISTENING - When a TCPIP server is ready to accept connection
- ESTABLISHED - When a TCPIP client receives a TCPIP server's SYN and the session is established
- CLOSE_WAIT - When a client side closes connection, this state appears on the server side.
- TIMED_WAIT - When a server side closes connection, then this state appears on the client side.
For example, the following output is displayed for the command:
netstat -anp tcp
TCP 22.214.171.124:7777 126.96.36.199:1132 ESTABLISHED
I hope this information helps provide some insight into TCPIP connection management. Let me know if there are any questions.