cURL / Mailing Lists / curl-library / Single Mail

curl-library

SV: Delays when uploading to Win2003 IIS 6.0 FTP server

From: Mehmet Bozkurt <mehmet.bozkurt_at_xware.se>
Date: Mon, 4 Oct 2010 12:25:08 +0200

>
> But I'm having a kind of odd behavior when uploading multiple files to
> the mentioned ftp server, using libcurl.
> The behavior I'm seeing is that after the last data transfer there is
> about a 2 second delay until the final server response "226 Transfer
> Complete" is returned. This does not happen for each run, but often
> enough to make the delay noticeable. Running the same test scenario
> against the same ftp server with a different ftp client does not show
> of any such delays.
> However, running the libcurl client against a vsFTPd (running on
> FreeBSD) I don't see the delay at all, but the ftp command/responses
> are slightly different compared to the IIS case because vsFTP supports
> EPORT, IIS 6 supports PORT only. Another difference is the FTP data
> packet size, uploading to IIS the size is 1460*3 and a final 1158
> bytes, for vsFTP the packet size is 1448*3 and a final 1194 bytes.
>
> I've attached a picture of the network traffic captured with Wireshark
> where these delays are visible.
>
> So my question is that if there is a possibility of libcurl keeping the
> data connection open for a while, in some cases, and then closing it,
> indicating and EOF?
>
>

I have done some more digging into this and I have found the spot where the
delay occurs.
But the reason to why it occurs is still confusing me.

In ftp.c there is a function called Curl_GetFTPResponse, which is called
from ftp_done (in the same file).

Curl_GetFTPResponse:
....
else {
      switch (Curl_socket_ready(sockfd, CURL_SOCKET_BAD, (int)interval_ms))
{
      case -1: /* select() error, stop reading */
        failf(data, "FTP response aborted due to select/poll error: %d",
              SOCKERRNO);
        return CURLE_RECV_ERROR;

      case 0: /* timeout */
          return CURLE_ABORTED_BY_CALLBACK;
        continue; /* just continue in our loop for the timeout duration */
....

the case 0: is triggered by Curl_socket_ready returning 0, which happens
when the delays are occurring.
An Curl_socket_ready returns 0 because of an select call timing out.
So the question is why the select call, called in Curl_socket_ready, is
sometimes timing out.
It's like the server is holding the final return data.

Has anyone seen this type of behavior before?

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-10-04