TCP/IP data transfer

You can use IBM® Integration Bus to connect to applications that use raw TCP/IP sockets for transferring data.

TCP/IP sockets provide a simple way of connecting computer programs together, and this type of interface is commonly added to existing stand-alone applications. TCP/IP provides a mechanism for transferring data between two applications, which can be running on different computers. The transfer of data is bidirectional; provided that the TCP/IP connection is maintained and no data is lost, the sequence of the data is kept. A significant advantage of using TCP/IP directly is that it is quick and simple to configure, which makes it a useful mechanism for processes that do not require message persistence (for example, monitoring).

However, the use of TCP/IP sockets for transferring information between programs does have some limitations:

• It is non-transactional
• It is not persistent (the data is written to an in-memory buffer between the sender and receiver)
• It has no built-in security
• It provides no standard way of signaling the start and end of a message

For these reasons, it can be preferable to use a transport mechanism like WebSphere® MQ, which has none of these limitations. However, if you have existing applications that use raw TCP/IP sockets for transferring data, you can use the IBM Integration Bus TCPIP nodes to connect to the applications without needing to enable them for WebSphere MQ, so that you can develop an IBM Integration Bus solution quickly.

A TCP/IP connection between two applications has a client end and a server end, which means that one application acts as a server and the other as a client. The terms client and server refer only to the mechanism used to establish a connection; they do not refer to the pattern of data exchange. When the connection has been established, both client and server can perform the same operations and can both send and receive data. The following diagram illustrates the locations of client and server applications:

1. 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.
2. The client application requests a connection from the server port, which the server then accepts.
3. When the server accepts the request, a port is created on the client computer and is connected to the server port.
4. A socket is created on both ends of the connection, and the details of the connection are encapsulated by the socket.
5. The server port remains available to listen for further connection requests:
   

The server can accept more connections from other client applications. These connections can be in the same process, in a different process on the same computer, or on a different computer:

Only one server application can exist, but any number of different client processes can connect to the server application. Any of these applications (client or server) can be multithreaded, which enables them to use multiple connections.

When the connection has been established, two data streams exist: one for inbound data and another for outbound data:

The client and server ends of the connection are identical and both can perform the same operations. The only difference between them is that the output stream of the client is the input stream of the server, and the input stream of the client is the output stream of the server.

The two streams of data are independent and can be accessed simultaneously from both ends. The client does not need to send data before the server.

The example illustrated in the previous diagram can be simplified in the following way, showing that the client and server have access to a socket that has an input stream and an output stream: