Re: FTP keep alive connection
Date: Mon, 05 Nov 2007 22:43:11 +0100
Patrick Monnerat a écrit :
> Patrick Monnerat wrote:
>> Right: the NOOP command must be supported. But the handling of the
>> connection while a data transfer is active is not well defined: this
>> the real potential problem. Light servers have the "permission" to
>> the control connection while transfering data. In that case, the
>> mechanism defined in RFC959 seems a bit hazardous...
> In addition, sending a NOOP to the server implies we should expect a 200
> response that is not handled at all by the current patch. When a data
> transfer is active, this response may come before or worse: even AFTER
> the data transfer completion response, because the server may have
> started to send the later while we are sending the NOOP :-(
> As a consequence, the handling of this asynchronous command/response
> exchange does not seem as simple as it first looks.
Well. Since this NOOP is not called, in this special case, like a
command, I do not expect at all any kind of response from the server. I
just need to send something, lightweight, in order to not be shut by a
strict piece of the network (router, firewall, ...).
That's why I do not check neither a response nor that the command was
correctly sent. If the connection is down, I won't be in the timer,
anyway. And I won't need to do anything too, I do not have to keep alive
a dead connection.
And, yes, I agree with you. I see it too as an option. Although for
me, this option would be more the interval between 2 calls of NOOP. My
default to 30s was intentionally hard coded since I needed a fast fix
and did not know at all the right way to get it as an option.
To conclude, I has chosen to send NOOP instead of SO_KEEPALIVE since
I do not have any hands on all the hardware on the network routes. The
default for SO_KEEPALIVE is every 2 hours. In my current use case, the
connection is shut after 15 minutes of inactivity.
Thanks all for your comment.
-- MichelReceived on 2007-11-05