Dan Fandrich wrote:
> On Tue, Mar 23, 2004 at 10:14:28AM -0600, Joe Halpin wrote:
>
>>Joe Halpin wrote:
>>
>>>I looked at it with ethereal. The client issues a RETR and the server
>>>starts sending a file. The client data port closes before the transfer
>>>is complete (the server doesn't notice this so there are a bunch of RST
>>>responses).
>>>
>>>When the server has sent the whole file it sends the 226 message, which
>>>results in a RST being returned on the control connection.
>>>
>>>It looks to me like the client crashed during the transfer. One I start
>>>seeing RST on the data connection there isn't any response of any kind
>>
>>>from the client. TCP just keeps sending RST.
>>
>>Sorry this isn't right. If the client crashed its TCP would have sent a
>>FIN to the server, but I don't see that in the output. The only thing I
>>can think of to explain this is that the client aborted the control
>>connection using SO_LINGER.
>
> But it did send a FIN to the server, at 0.005494 seconds in the log,

This was where the data connection was closed by the client.

> another one to the control port at 0.05634 seconds.

Ahh, you're right I misread the port number, sorry.

> It does look like the
> client unceremoniously closed the ftp connection in the middle of the
> file transfer, rather than some exotic abort mechanism.

I'm also curious as to why the server doesn't realize the connections
(at least the data connection) have been closed. It really shouldn't
take more than two or three sends before you get SIGPIPE or a return of
-1 from write().

>>Mike, earlier on you said you "do a cleanup of the curl_handle and
>>create a new one to continue the download". Are you using SO_LINGER when
>>doing this? If not, how are you cleaning up the handle?

Joe
Received on 2004-03-23