Re: lynx-dev RFC959 non-compliance in Lynx hangs the client

[Gregory A Lundberg]

I believe the problem wiht the libwww FTP implementation is what is called
'nominal realism'.

In this case I mean the confusion of the RFC 959 (et al) term 'close' with
the C function of the same name: close().

The FTP RFCs do not make reference to C.  Rather, they quite specifically
refer the reader to the TELNET and TCP RFCs.

In those documents we find the definition of 'closed' in reference to a TCP
connection:

RFC 793 3.2 Terminology (pg 21)

  A connection progresses through a series of states during its
  lifetime.  The states are:  LISTEN, SYN-SENT, SYN-RECEIVED,
  ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK,
  TIME-WAIT, and the fictional state CLOSED.  CLOSED is fictional
  because it represents the state when there is no TCB, and therefore,
  no connection.  Briefly the meanings of the states are:


    LISTEN - represents waiting for a connection request from any remote
    TCP and port.

    SYN-SENT - represents waiting for a matching connection request
    after having sent a connection request.

    SYN-RECEIVED - represents waiting for a confirming connection
    request acknowledgment after having both received and sent a
    connection request.

    ESTABLISHED - represents an open connection, data received can be
    delivered to the user.  The normal state for the data transfer phase
    of the connection.

    FIN-WAIT-1 - represents waiting for a connection termination request
    from the remote TCP, or an acknowledgment of the connection
    termination request previously sent.

    FIN-WAIT-2 - represents waiting for a connection termination request
    from the remote TCP.

    CLOSE-WAIT - represents waiting for a connection termination request
    from the local user.

    CLOSING - represents waiting for a connection termination request
    acknowledgment from the remote TCP.

    LAST-ACK - represents waiting for an acknowledgment of the
    connection termination request previously sent to the remote TCP
    (which includes an acknowledgment of its connection termination
    request).

    TIME-WAIT - represents waiting for enough time to pass to be sure
    the remote TCP received the acknowledgment of its connection
    termination request.

    CLOSED - represents no connection state at all.

  A TCP connection progresses from one state to another in response to
  events.  The events are the user calls, OPEN, SEND, RECEIVE, CLOSE,
  ABORT, and STATUS; the incoming segments, particularly those
  containing the SYN, ACK, RST and FIN flags; and timeouts.



Hence, we find that the definition of 'close' for the FTP is "no connection
state at all".

Pragmatically, this was found to be a _bit_ to restrictive.  The TCP
LAST-ACK and TIME-WAIT states were causing far too long a wait between data
transfers.  For this reason, the requirement was added that a new PORT or
PASV command must preceed each transfer command.  By choosing a new port
pair, the connection was, by definition, CLOSED and ready to be established
again.

To properly implement the FTP, the server (who is assigned this
responsibilty) must have some way to determine the data connection is in
the CLOSED state.  Or at least that the connection is in the LAST-ACK or
TIME-WAIT states, since those represent simply timeouts and no network
traffic.

The question is how to detect this.  And, for WU-FTPD, how to detect it in
a portable way.  By use of the shutdow() function, we can begin the TCP
CLOSE on the connection.  What we need is some way to determine when the
remote (client or server) has also closed (via shutdown() or close()) the
connection.  The suggested method .. and I see no other .. was to read()
from the data connection, awaiting an EOF indication, with an appropriate
timeout, of course, to allow for complete loss of communications.

If someone has some better means to _portably_ detect that the remote end
has FIN/ACK'd our FIN, I would be very interested to hear about it.

-- 

Gregory A Lundberg              WU-FTPD Development Group
1441 Elmdale Drive              address@hidden
Kettering, OH 45409-1615 USA    1-800-809-2195

pgpEB2Pzy9Joq.pgp
Description: PGP signature