[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev RFC959 non-compliance in Lynx hangs the client
From: |
Klaus Weide |
Subject: |
Re: lynx-dev RFC959 non-compliance in Lynx hangs the client |
Date: |
Tue, 7 Sep 1999 20:42:50 -0500 (CDT) |
On Tue, 7 Sep 1999, Gregory A Lundberg wrote:
> [ S->C ] 200 PORT command successful.
>
> [ Note to WU-FTPD Development Group: As I've noted before, we should be
> establishing the data connection at this point. ]
Is there any real gain form this proposed change except stricter
compliance to the written spec? You might wee be the first one
to try it...
[...]
> [ Note to Lynx developers: At this point, you should issue another PORT
> command, or a PASV command.
I think that means a PORT for a _different_ port, to avoid sockets reuse
problems. So correct servers require more socket wastage...
Anyway, to a different (the original) topic:
If you just want to make sure that the last data packet has reached
the client host, all you have to do is wait for an ack for that last
data sequence number. If you want to make sure the FIN has reached
the client host too, wait for an ACK for that FIN. That's at the TCP
protocol level; whether there is a convenient way to get this info
from the ususal socket API is another question...
> 08:58:26.370766 ftp.wu-ftpd.org.ftp-data > ftp.wu-ftpd.org.14447: S
> 08:58:26.370766 ftp.wu-ftpd.org.14447 > ftp.wu-ftpd.org.ftp-data: S
> 08:58:26.370766 ftp.wu-ftpd.org.ftp-data > ftp.wu-ftpd.org.14447: . ack 1
>
> [ Data connection established. ]
>
> 08:58:26.370766 ftp.wu-ftpd.org.ftp-data > ftp.wu-ftpd.org.14447: P
> 1:380(379) ack 1
>
> [ S->C ] total 16
> [ S->C ] d--x--x--x 2 root root 1024 Jul 19 12:19 bin
> [ S->C ] d--x--x--x 2 root root 1024 Jan 12 1999 dev
> [ S->C ] d--x--x--x 2 root root 1024 May 25 1999 etc
> [ S->C ] drwxrwx-wx 2 root wuftpd 1024 Sep 3 22:10 incoming
> [ S->C ] drwxrwx--x 4 root wuftpd 2048 Aug 26 16:50 private
> [ S->C ] drwxrwxr-x 6 root wuftpd 2048 Jul 9 07:43 pub
>
> 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
>
> [ FTP server is waiting for Lynx to close down the socket. ]
>
> [ Time passes ]
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.
Klaus
- lynx-dev RFC959 non-compliance in Lynx hangs the client, Gregory A Lundberg, 1999/09/07
- Re: lynx-dev RFC959 non-compliance in Lynx hangs the client, David Woolley, 1999/09/09
- Re: lynx-dev RFC959 non-compliance in Lynx hangs the client, David Woolley, 1999/09/09
- Re: lynx-dev RFC959 non-compliance in Lynx hangs the client, Gregory A Lundberg, 1999/09/09
- Re: lynx-dev RFC959 non-compliance in Lynx hangs the client, Klaus Weide, 1999/09/10
- Re: lynx-dev RFC959 non-compliance in Lynx hangs the client, Gregory A Lundberg, 1999/09/10
- Re: lynx-dev RFC959 non-compliance in Lynx hangs the client, Klaus Weide, 1999/09/11