Re: FTPAPI connection reset

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

On 3/1/2012 3:15 PM, Charles Wilt wrote:
> Sure, I think I describe that in one of my messages.  But I think
> something in the network side of things is killing the command
> channel.

In the network? Really?

Back in the dial-up days that would happen.  Because, in some 
circumstances, it costs money to keep a telephone line open (either the 
telco charged by the minute, or the ISP did...), there was software that 
would watch for traffic on the line. If no traffic was after a 
preconfigured "time-out" period, it'd disconnect the modem.

Interestingly, some software would send extra data on a timer just to 
prevent the modem from doing that...

However, that doesn't fit this scenario, because in that scenario, it'd 
only disconnect if there was no network traffic. It didn't make sense to 
look at individual TCP sessions, since you could only disconnect if 
there was no traffic at all.

Why would you cut off a single TCP session?

>
> Understood.  Unfortunately, there's no indication in the logs as to
> which socket is getting the error.
>

If the error is occuring on the reply() call, it has to be the control 
connection.


>
> Not sure about that, the STOR worked, as the data channel was opened
> and the file sent.
>

Right... but what if an extra character somehow got appended to the STOR 
command that came after the CRLF at the end?  Or if you put a CRLF in 
your actual call to ftp_put()?  The STOR command would work, but extra 
characters after the CRLF would be treated as a new command.

That's probably not what's happening...  I'm just trying to figure out 
what would cause the problem...


> My thinking is that while the file is being transferred,  the data
> channel is obviously active and the command channel is not.

Data is being sent on the data channel, and not on the control 
channel... but, a properly written FTP server shouldn't be coded to 
disconnect the control channel while it's waiting for the data channel 
to complete.  Why would you code it that way?  You'd have nowhere to 
send your completion message...  Doesn't make much sense to me.

I'm not sure how you could send a NOOP while a transfer is active. 
Won't the server be busy receiving the file at that point, and not ready 
to receive commands (aside from ABOR)?  Even if it spawns a new thread 
to handle the data connection, it still has to be in a state that's 
waiting for the transfer to complete in order to send the 226/250.

If you allowed it to send other commands while the transfer is active, 
what would happen when the 226/250 response finally came through?  You 
wouldn't know which of your commands it was in response to.

The normal case where someone gets a timeout due to inactivity in FTP is 
when you have an *interactive* FTP session.  What happens is:  The user 
starts a file transfer, and it's taking awhile, so he walks away, or 
flips to another window, or maybe even goes home for the night.  (I've 
done that, for example, when downloading PTFs from IBM).  When the 
transfer is complete, the user isn't there to type another command, so 
it eventually times out, and the server disconnects.  When the user 
comes back to it, he might type a command thinking it's still active, 
but get a "Connection reset", since the server won't ever receive the 
data he typed.

That's very different from this circumstance, because the error is 
occurring when reading the file transfer reply, not when waiting for a 
user or sending a new command after a long inactivity.

If the server is really timing out the command channel while the data 
channel is active, that's a bug in the server code.  It's not the way 
it's supposed to work.  And I don't think there's any reliable way to 
code around it on the client side.  (Not a way that'll work with all FTP 
servers, at any rate.)

> After the file is transferred, FTPAPI closes the data channel and
> looks for a reply on the command channel.  If the command channel had
> been killed by something in the network, wouldn't the TCP/IP stack
> throw the "Connection reset" error when FTPAPI tries to receive the
> reply?

Sure... if a 3rd party (not the FTP server or client, but something 
else) disconnected the channel, that would happen.

But... why?  Why would they ever do that?  Why would it care which 
individual TCP sessions are active or inactive?  It's hard to find any 
motivation for that.  And, at any rate, I don't see how I can code 
around it in FTPAPI.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------