We're seeing a problem when libcurl closes a control connection without
sending a QUIT command. The sequence described in STD 9 is:

<quote>
7. TYPICAL FTP SCENARIO

    User at host U wanting to transfer files to/from host S:

    In general, the user will communicate to the server via a mediating
    user-FTP process. The following may be a typical scenario. The
    user-FTP prompts are shown in parentheses, '---->' represents
    commands from host U to host S, and '<----' represents replies from
    host S to host U.

       LOCAL COMMANDS BY USER ACTION INVOLVED

       ftp (host) multics<CR> Connect to host S, port L,
                                      establishing control connections.
                                      <---- 220 Service ready <CRLF>.
       username Doe <CR> USER Doe<CRLF>---->
                                      <---- 331 User name ok,
                                                need password<CRLF>.
       password mumble <CR> PASS mumble<CRLF>---->
                                      <---- 230 User logged in<CRLF>.
       retrieve (local type) ASCII<CR>
       (local pathname) test 1 <CR> User-FTP opens local file in ASCII.
       (for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
                                      <---- 150 File status okay;
                                            about to open data
                                            connection<CRLF>.
                                      Server makes data connection
                                      to port U.

                                      <---- 226 Closing data connection,
                                          file transfer successful<CRLF>.
       type Image<CR> TYPE I<CRLF> ---->
                                      <---- 200 Command OK<CRLF>
       store (local type) image<CR>
       (local pathname) file dump<CR> User-FTP opens local file in Image.
       (for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
                                      <---- 550 Access denied<CRLF>
       terminate QUIT <CRLF> ---->
                                      Server closes all
                                      connections.
</quote>

Here's some tcpdump output of the close sequence. If I understand this
correctly it shows that the client (running libcurl) does a full close.
The standard shows the server doing the active close. I've talked this
over with some of my coworkers, and we suspect the fact that libcurl
doesn't send QUIT and let the server do the active close has the
following consequences:

1. The client (ie, libcurl) calls close(), which makes it unable to
receive anything but a FIN in response.

2. The server sends a message complaining that QUIT wasn't sent, and
then sends a FIN. However, since libcurl has already called close(),
resets get sent, which keeps the connection from being cleanly shutdown.
In our case this results in a lot of stale connections and timeouts on
the server side.

20:40:03.156906 client.50040 > server.1921: F 1:1(0) ack 864 win 24820 (DF)
20:40:03.157256 client.50031 > server.ftp: F 94:94(0) ack 486 win 24820 (DF)
20:40:03.306787 server.ftp > client.50031: . ack 95 win 8192
20:40:03.311061 server.ftp > client.50031: P 486:523(37) ack 95 win 8192
0x0000 4500 004d 7980 0000 2f06 e6f8 2fa6 3af8 E..My.../.../.:.
0x0010 2f68 912c 0015 c36f 4d03 53a3 7a61 27dd /h.,...oM.S.za'.
0x0020 5018 2000 6cde 0000 3232 3120 596f 7520 P...l...221.You.
0x0030 636f 756c 6420 6174 206c 6561 7374 2073 could.at.least.s
0x0040 6179 2067 6f6f 6462 7965 2e0d 0a ay.goodbye...
20:40:03.311089 client.50031 > server.ftp: R 2053187549:2053187549(0)
win 24820 (DF)
20:40:03.311430 server.ftp > client.50031: F 523:523(0) ack 95 win 8192
20:40:03.311444 client.50031 > server.ftp: R 2053187549:2053187549(0)
win 0 (DF)

I'd be willing to supply a patch to fix this, but I'm not familiar
withthe development environment here. Can you point me to a document
that describes how to submit a patch, what format the patch has to be
in, etc?

Thanks

Joe

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
Received on 2004-01-09