In an attempt to solve this problem, the TCP specifications include a way to send keep-alive packets on otherwise idle TCP connections, to tell all involved parties that the connection is still alive and needed. But since the control connection got dropped without notification, the reply never arrives and eventually the connection will timeout. Likewise, the client thinks the control connection is alive and it waits for the reply from the server. So when all data has been transferred, the server assumes the control connection is alive and it sends the transfer confirmation reply. For FTP, this means that during a long transfer the control connection can get dropped because it is detected as idle, but neither client nor server are notified. However, many routers and firewalls automatically close idle connections after a certain period of time. Unless explicitly closed, a connection is supposed to remain alive indefinitely.
The TCP specifications do not set a limit on the amount of time a connection can stay idle. It is the nature of FTP that during a transfer the control connection stays completely idle. If you can transfer small files without any issues, but transfers of larger files end with a timeout, a broken router and/or firewall may exist between the client and the server and is causing a problem.įTP uses two TCP connections: a control connection to submit commands and receive replies, and a data connection for actual file transfers.
0 kommentar(er)
