Bugs item #2844077, was opened at 2009-08-25 09:15
Message generated for change (Settings changed) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2844077&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: wrong behaviour
Status: Open
>Resolution: None
>Priority: 4
Private: No
Submitted By: Mosh_itup (moshitup)
Assigned to: Daniel Stenberg (bagder)
Summary: libcurl (ftp) don't consider CURLOPT_CONNECTTIMEOUT

Initial Comment:
libcurl using FTP don't consider the CURLOPT_CONNECTTIMEOUT
(Tested under Windows XP, curl Version 7.19.6 and also 7.19.5, other versions I did not tried)

After the curl_easy_perform() it takes CURLOPT_TIMEOUT seconds instead of CURLOPT_CONNECTTIMEOUT.

Example-code illustrating the bug:

      gFTP.hFTP[iServerid-1] = (int)curl_easy_init();
      curl_easy_setopt((void*)gFTP.hFTP[iServerid-1],CURLOPT_URL,"ftp://172.99.99.99"); //TEST! only to simulate an ftp-adress which is not reachable
      curl_easy_setopt((void*)gFTP.hFTP[iServerid-1],CURLOPT_PORT,INTERNET_DEFAULT_FTP_PORT);
      curl_easy_setopt((void*)gFTP.hFTP[iServerid-1],CURLOPT_ERRORBUFFER,sErrorBuf);
      curl_easy_setopt((void*)gFTP.hFTP[iServerid-1],CURLOPT_WRITEFUNCTION, writeFunctionConnect);
      curl_easy_setopt((void*)gFTP.hFTP[iServerid-1],CURLOPT_TIMEOUT,300); //transfer operation timeout
      curl_easy_setopt((void*)gFTP.hFTP[iServerid-1],CURLOPT_CONNECTTIMEOUT,30); //connection timeout
      curl_easy_setopt((void*)gFTP.hFTP[iServerid-1],CURLOPT_FTP_FILEMETHOD,CURLFTPMETHOD_SINGLECWD);
      curlReturn = curl_easy_perform((void*)gFTP.hFTP[iServerid-1]);

I debugged into curl in ftp.c.
My proposal for solution:

static long ftp_state_timeout(struct connectdata *conn)
{
  struct SessionHandle *data=conn->data;
  struct ftp_conn *ftpc = &conn->proto.ftpc;
  long timeout_ms=360000; /* in milliseconds */

  if(data->set.ftp_response_timeout )
    /* if CURLOPT_FTP_RESPONSE_TIMEOUT is set, use that to determine remaining
       time. Also, use ftp->response because FTP_RESPONSE_TIMEOUT is supposed
       to govern the response for any given ftp response, not for the time
       from connect to the given ftp response. */
    timeout_ms = data->set.ftp_response_timeout - /* timeout time */
      Curl_tvdiff(Curl_tvnow(), ftpc->response); /* spent time */
  else if(data->set.timeout)
  {
    /* if timeout is requested, find out how much remaining time we have */
    if(ftpc->state == FTP_WAIT220)
        {
          /* we're during connect */
          if(data->set.timeout < data->set.connecttimeout)
                 timeout_ms = data->set.timeout - Curl_tvdiff(Curl_tvnow(), conn->now); /* spent time */
          else
                 timeout_ms = data->set.connecttimeout - Curl_tvdiff(Curl_tvnow(), conn->now); /* spent time */
        }
        else
        {
          timeout_ms = data->set.timeout - Curl_tvdiff(Curl_tvnow(), conn->now); /* spent time */
        }
  }
  else
    /* Without a requested timeout, we only wait 'response_time' seconds for
       the full response to arrive before we bail out */
    timeout_ms = ftpc->response_time -
      Curl_tvdiff(Curl_tvnow(), ftpc->response); /* spent time */

  return timeout_ms;
}

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

>Comment By: Daniel Stenberg (bagder)
Date: 2009-08-28 14:43

Message:
I think I can guess what's happening.

Your TCP connection is done at this point and the code you look at is the
FTP-specific code that follows after the completion of the TCP handshake.
That phase could of course be seen as part of the connection and thus
subject to that particular timeout, but currently isn't...

To make it adhere to the connect timeout, we need to pass on the fact that
it is still in connect phase into the ftp state machine to allow it to use
a different timeout.

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

Comment By: Mosh_itup (moshitup)
Date: 2009-08-28 14:35

Message:
Hi bagder,
well, you should know the code better than I ;-)
But just try it out, and you'll see.
If you set a breakpoint into this function while the ftp-connect is in
progress, you'll see, that there is no reference to the
set.connecttimeout-variable but only to the set.timeout.
Therefore it takes 300 seconds instead of 30.
Afterwards, (the loop for connect has ended), then libcurl "detects" that
a timeout has occured, but then it is too late!
So you are convinced the CONNECTTIMEOUT works already, but what I see is
totally different!
Have a nice day!

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

Comment By: Daniel Stenberg (bagder)
Date: 2009-08-27 20:04

Message:
Hm, the fix couldn't be in ftp.c since that code is not responsible for the
initial connect (and its timeout).

I'm quite convinced this works already, and the connection code is
protocol agnostic and thus works the same for all (TCP-based) protocols.

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2844077&group_id=976
Received on 2009-08-28