Contributed by merdely on from the stayin-alive dept.
Recently, Marc Espie (espie@) reminded us on ports@ that FTP is broken. "So a file transfer goes like this: send some commands, open a data connection, and transfer the file... during the transfer, the control connection stays silent... that is, totally silent. And then, we come back up, and there is NO control connection left. Over the lousy five minutes it took us to transfer the file," the network expired the control connection.
To attempt to make ftp(1) work better, Marc committed code to:
implement a `keep-alive' option that sends bytes over an inactive connection. The FTP protocol provides us with a NOOP operation that is perfectly suitable for that, and so far servers are happy with it. Sending the command slowly is an idea I borrowed from spamd. No change for people not using the option, so it can't break normal ftp.
A new "-k" option was added to the ftp command:
-k seconds Sends a byte after each seconds period over the control connec- tion during long transfers, so that incorrectly configured net- work equipment won't agressively drop it. The FTP protocol sup- ports a NOOP command that can be used for that purpose. This as- sumes the FTP server can deal with extra commands coming over the control connection during a transfer. Well-behaved servers queue those commands, and process them after the transfer.
As Marc then announced on ports@:
[The -k option] doesn't solve the other ftp problem, that in many cases you may have an intermediate proxy that does not understand telnet correctly, and so your urgent ABORTs won't get through correctly, and it will take forever for pkg_add to close connections early (we solved this in our ftp-proxy a few years ago).
So, from pkg_add, you can try out to set the env variable FTP_KEEPALIVE if you think you have the problem... one common symptom is to have the installation of openoffice hanging at the end.
(Comments are closed)