lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gregory A Lundberg
Subject: Re: lynx-dev RFC959 non-compliance in Lynx hangs the client
Date: Thu, 9 Sep 1999 11:05:13 -0400

On Tue, Sep 07, 1999 at 08:42:50PM -0500, Klaus Weide wrote:

> > 08:58:26.370766 ftp.wu-ftpd.org.14447 > ftp.wu-ftpd.org.ftp-data: . ack 381
> 
> Note that that ack doesn't just acknowledge all of the data, but the 381
> includes the FIN shown below.  (For some reason they got reordered,
> shouldn't happen except for localhost.)
> 
> > [ C->S Naggle ]
> > 
> > 08:58:26.370766 ftp.wu-ftpd.org.ftp-data > ftp.wu-ftpd.org.14447: F 
> > 380:380(0) ack 1

You are correct.  I tried to re-order the tcpdump to account for the fact I
was doing this on localhost.  I missed one.

> If you want to ensure that the last data and EOF has been seen by the
> client _application_ rather than just by the host it's running on, before
> you contine the conversation on the control connection, then it's a
> different matter.  If you would (could) wait for just the ACK to the
> server's FIN, you would be sure that the client *can* get all the data
> (it's already on that client's host), so it's more clearly that client's
> fault and not the network's if it doesn't do that when it sees a 2xy
> response.

If we were writing a daemon for a specific platform's IP stack (say, MS
Windows NT 4 SP5), we could reach down into the stack to watch the ACK
traffic.  As you point out, though, this does not tell us if the client
application has seen the traffic, only that it _could_ if it wanted to.

Unfortunately, there is no portable way to handle low-level protocol
issues.  So we're left with that which _is_ defined: the shutdown() and
close() functions.

We could simply do a close(), but that would not tell us if the client-side
has seen it before we send the 2yz reply.

We could try to use SO_LINGER, but that will only tell us the packets have
been sent when we do a close(); not that the client application has acted
upon them.

The intention is not to ensure the client's host has the traffic.  It is to
ensure the CLIENT itself sees the remaining data BEFORE it sees the 2yz.
Why?  To support poorly written clients.  Do we know of any?  No.  We got
the suggestion from an RFC author as part of his research into a
clarification of this part of the protocol.

That leaves us with shutdown(), which closes the socket on our end,
followed by a read() to await an EOF (shutdown()/close()) from the client.
This is what the wu-ftpd daemon is now doing.  In fact, if the user were
not so impatient, things would eventually have worked.  The daemon has a
timeout on the read() and would have proceeded eventually.  Unfortunately,
that timeout is long (to allow for slow network connections .. 20 minutes
by default), and the user impatient, so the session was terminated by
resetting the client-side.

-- 

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

Attachment: pgpFN7Y0MDwCZ.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]