Thank you; it seems so, yes--either the FTPS servers or some other piece of routing equipment between the client and the FTPS servers intermittently drops the connection.
We connect to an Axway SecureTransport server, v4.9.1. This server listens on FTPS control port 2121 in an Internet-facing DMZ. For data transfers, the DMZ server directs the client to one or more different backend servers on a non-privileged port (e.g., 5050).
For testing purposes, we have initiated FTPS transfers from various networks using various clients: our work site; an Amazon EC2 server; another work site's equipment; and my personal equipment--all seem to intermittently timeout. The consistent, intermittent failures despite originating network seems (to me) a clue the issue may lie with routing equipment in or near the FTPS server.
FTPS server support staff suggest we try transferring the file using software capable of sending KeepAlives to the FTPS control port during the transfer. They think routing equipment may close the FTPS control port due to lack of activity during a long transfer on the data port, which would timeout the session. I assume the data port, over which the transfer takes place, would not timeout (?).
Thus, we would like to see which FTPS clients may send KeepAlives to the control port during long transfers over the data port (or an option to do so, perhaps). WinSCP also has scripting support and runs on Windows, which would allow us to automate the download.
Thank you again.
Reply with quote