cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: FTP keep alive connection

From: Loiseleur Michel <mloiseleur_at_linagora.com>
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
> control
>> connection while a data transfer is active is not well defined: this
> is
>> the real potential problem. 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...
>
> 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.

Regards,

-- 
Michel
Received on 2007-11-05