Patrick Monnerat wrote:
> >> I think it must be an option, since this is not guaranteed by RFC959
> >> to be properly processed by all servers.
>
> > Actually it is. From RFC959:
>
> Right: the NOOP command must be supported. But the handling of the
> control connection while a data transfer is active is not well defined:
> this is the real potential problem.

ok.

> Light servers have the "permission"
> to ignore the control connection while transfering data. In that case,
> the attention mechanism defined in RFC959 seems a bit hazardous...

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? If so, that doesn't seem too harmful.

> > SO_KEEPALIVE isn't available on all platforms with TCP, though.
>
> Agreed, although most of them support it. Anyway, it should be an option
> too.

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

By default (without SO_KEEPALIVE), TCP connections remain open with no
timeout. It's only when data is sent unsuccessfully that the TCP send
operation may timeout after a few minutes.

Timeouts are usually handled at the application layer.

FTP servers implement a timeout by closing the connection when they
haven't received a command for some time. (Though some of them seem
to timeout even if they have, strangely.)

SO_KEEPALIVE by the client won't change that. The server still won't
receive anything that's noticed by the application, and it will still
close the connection after that time.

-- Jamie
Received on 2007-11-06