Jamie Lokier wrote:

> Does that mean you can send them NOOP, and they'll just not read it
until finishing the data transfer, at which point they'll send the
response to NOOP?

Possible. But as I already mention, this is not very well defined by the
RFC. However if the behavior is as you describe (although not
guaranteed), you might think it's OK (although useless) considering a
single NOOP. If several of them are issued, there might be potential
issues in the client and/or server OS (TCP buffer resources overflow,
for example).

> Come to think of it, I don't think SO_KEEPALIVE will keep a control
connection open anyway.

Please read my original comment about SO_KEEPALIVE: it helps keeping the
connection alive in FIREWALLS, not in the target FTP server. This is
very important, since a connection dropped by a firewall is definitely
broken and neither the client nor the server are informed of this
situation.

Simple firewalls do not perform FTP deep inspection and process each TCP
connection for itself, without knowing that a (FTP control) connection
is bound to another (FTP data) connection: for those firewalls, the
control connection is just an inactive connection while data transfer is
active. If the data transfer is long, inactivity on the control
connection may lead in a timeout situation for that connection, causing
the firewall to drop it. SO_KEEPALIVE (associated with keep-alive
timeout adjustments in the firewall and/or client OS) may create
transparent activity on the control connection without disturbing the
FTP protocol itself.
Received on 2007-11-07