An example of distributed connections

This example illustrates two users connecting into a sysplex with distributed connections. To simplify the illustration, only three LPARs are displayed.

Figure 1. Distributed connections

Both users are using FTP clients. Here is the sequence of events as they transpire for the desktop workstation:

The FTP client issues a connection request to 10.134.61.190.
The request is received at LPAR 1.
WLM indicates that LPAR 2 should handle this connection.
The connection request is redirected (forwarded) to LPAR 2 over a dynamic XCF link.
LPAR 2's FTP server responds to and accepts the connection request. The source IP address used is 10.134.61.190 (otherwise the connection would fail at the FTP client end).
The FTP session continues as usual.

Next, a notebook user starts an FTP client and attempts to connect to 10.134.61.190. This time, in step 3, WLM indicates that the next connection should not be redirected at all. Instead, this connection is completed without any distribution performed.

Some questions might pop into your head at this time. You may be thinking, "Shouldn't the FTP environments have to be the same on all LPARs to ensure that users always appear to be connecting to the same server?" Yes, you're correct.

And this can be accomplished in a couple of ways:

z/OS can share DASD (disks) within the sysplex so that each FTP server accesses the same environment.
If it is a retrieve-only FTP environment (no PUT of files allowed), then the file systems could readily be duplicated within each LPAR's environment.

Another question you might have depends upon your knowledge of how FTP works. Each time a data transfer request (or even a dir or ls command) is made in FTP, a separate and new connection must be established. FTP has two ways it can establish the data connection: by using a PORT command or a PASV command (for details, see RFC 959).

PORT command

The PORT command method of establishing the data connection requires the FTP server to send a connection request back to the client. Such a scenario is not complicated by its occurring within a distributed sysplex because an outbound connection does not need to use the distributor. The connection request heads outbound over the appropriate link directly to the host where the FTP client is running.

FTP PASV command

In contrast, an FTP PASV command requires that the data connection is established by the client sending a connection request to the server. When this data connection arrives at the distributing host, how does it know which FTP server owns the existing control connection? The answer is that the distributing host is state-aware, in much the same fashion as a stateful firewall. The distributing host keeps track of any inbound TCP connections. In addition, the distributing host is also made aware of target hosts establishing outbound connections, though it needs to keep track only of outbound connections that use the distributed address as a source address.

One final thing to note in Figure 1 is that responses from target servers do not need to return through the distributing host. Instead, they can follow a direct return path.