Although the FTP data and control connections are separate TCP connections, the two channels are correlated. For example, the sender requests to close the data connection over the control channel when a file has finished transmitting.

With WAN optimization in place, the sender can incorrectly believe that the file transfer has complete and send a request over the control channel to prematurely close the data connection. Because the SteelHead acts as a TCP proxy, the sender is actually communicating with the local SteelHead. In certain environments with high latency or low data reduction, the local SteelHead can still be sending the file, but the sender sends the request to close the data connection before the file is completely finished.

If you find that the data connection is closing prematurely, you can adjust a manual delay to the sender request. Use the command protocol ftp delay-close-sec <time-in-seconds> on the SteelHead local to the FTP server. Riverbed recommends 30 seconds for most environments.