Bugs item #1826056, was opened at 2007-11-05 14:53
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1826056&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ftp
>Group: new feature request
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Michel Loiseleur (mloiseleur)
Assigned to: Daniel Stenberg (bagder)
Summary: Keep tcp connections alive

Initial Comment:
When retrieving a ftp file, curl do not ensure that the control socket is alive during time.

If one download a big file, the connection could be close close before completion : A firewall or a router has close the connection, because it seems inactive.

A common answer to this problem is to send "NOOP" command, in order to keep the connection up.

The attached patch, made against official curl 7.17.1, is a first attempt to get this feature into curl.

Would you please review it ?

I didn't know how to include it proprely with other options so I kept, for the moment, the timeout parameter directly in the function.

Regards,

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2007-11-05 16:42

Message:
Logged In: YES
user_id=1110
Originator: NO

Thanks for your contribution!

First, this isn't actually a bug. It is like this by design. So, I'd like
you to post this patch and take the discussion about it to the curl-library
mailing list.

A few quick comments on the patch:

#1 - no need to include changes to the .Plo files, they're generated

#2 - the "int FTP_TIMEOUT" is a C99ism and we need C89 compliance (all
variables declared at the top before the code)

#3 - The module check for the time spent is not really a timeout and it
could easily: a) be missed if it wasn't called that exact second and b) if
there's a very slow communication with the server the transfer may in fact
not have started and then your "NOOP" command will cause much confusion and
c) the most hard-to-fix part is that the function may not be able to send
the whole chunk of data in this invoke. I figure a temporary fix for that
is to use the function that isn't non-blocking but that sends the data in a
blocking way.

Now, I'll close this bug report. Please take follow-ups to the mailing
list as I suggested above!

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1826056&group_id=976
Received on 2007-11-05