Bugs item #1465999, was opened at 2006-04-06 23:34
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1465999&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: bad behaviour
>Status: Closed
Resolution: Accepted
Priority: 2
Submitted By: Robson Braga Araujo (braga)
Assigned to: Daniel Stenberg (bagder)
Summary: Libcurl doesn't reuse connection after aborting transfer.

Initial Comment:
Libcurl disconnects from the FTP server when I remove
the easy handle from a multi handle to stop the
transfer. This is not necessary as libcurl maintains
the connection if I pass a range of the form X-Y. The
following testcase shows this bad behaviour. I tested
it against latest CVS (7.15.3-20060406).

#include <stdio.h>
#include <curl/curl.h>
#include <curl/easy.h>

int main() {
  CURL *c;
  CURLM *m;
  CURLMcode res;
  int running=1;
  int i=0;

  curl_global_init(CURL_GLOBAL_ALL);
  c = curl_easy_init();
  curl_easy_setopt(c, CURLOPT_VERBOSE, 1);
  curl_easy_setopt(c, CURLOPT_URL, "ftp://ftp.sunet.se/");
  curl_easy_perform(c);
  curl_easy_setopt(c, CURLOPT_URL,
"ftp://ftp.sunet.se/ls-lR");
  m = curl_multi_init();

  res = curl_multi_add_handle(m, c);

  do {
     res = curl_multi_perform(m, &running);
  } while (res==CURLM_CALL_MULTI_PERFORM);
  while (running) {
    struct timeval timeout;
    int rc; /* select() return code */

    fd_set fdread;
    fd_set fdwrite;
    fd_set fdexcep;
    int maxfd;

    FD_ZERO(&fdread);
    FD_ZERO(&fdwrite);
    FD_ZERO(&fdexcep);

    /* set a suitable timeout to play around with */
    timeout.tv_sec = 1;
    timeout.tv_usec = 0;

    /* get file descriptors from the transfers */
    curl_multi_fdset(m, &fdread, &fdwrite, &fdexcep,
&maxfd);

    rc = select(maxfd+1, &fdread, &fdwrite, &fdexcep,
&timeout);

    switch(rc) {
    case -1:
      /* select error */
      break;
    case 0:
      /* timeout, do something else */
      break;
    default:
      /* one or more of curl's file descriptors say
there's data to read
         or write */
      while(CURLM_CALL_MULTI_PERFORM ==
            curl_multi_perform(m, &running));
      break;
    }
    if (i++ > 10) break;
  }

  curl_multi_remove_handle(m, c);
  curl_easy_setopt(c, CURLOPT_URL, "ftp://ftp.sunet.se");
  res = curl_multi_add_handle(m, c);

  while (running) {
    res = curl_multi_perform(m, &running);
    if (running <= 0) {
      fprintf(stderr, "nothing left running.\n");
      break;
    }
  }
  curl_multi_remove_handle(m, c);
  curl_easy_cleanup(c);
  curl_multi_cleanup(m);

  return res;
}

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

>Comment By: Daniel Stenberg (bagder)
Date: 2006-04-19 01:15

Message:
Logged In: YES
user_id=1110

Committed now, with only a little minor edits by me.

Thanks a lot!

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

Comment By: Robson Braga Araujo (braga)
Date: 2006-04-07 16:42

Message:
Logged In: YES
user_id=307089

How about the attached patch? It first tries to get a
response from the server. If the server doesn't answer, I
don't think it matters if we return CURLE_PARTIAL_FILE or
another error. If the server answers, it is an error code
because we used the range option and we didn't get the
ammount of bytes that we were expecting, we return
CURLE_PARTIAL_FILE.

The big advantage is that it reuses the connection if we
just cancel the download for some reason.

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

Comment By: Daniel Stenberg (bagder)
Date: 2006-04-07 14:37

Message:
Logged In: YES
user_id=1110

I agree it could re-use such connections and that libcurl is
doing this to "play safe" atm.

I have no immediate plans to work on this myself, but I'll
leave this bug report open for a while should anyone else
feel like taking a stab at fixing this.

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1465999&group_id=976
Received on 2006-04-19