Re: FTPAPI connection reset

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

On 3/1/2012 6:54 PM, Charles Wilt wrote:
>
> Why wouldn't you?  :)  If you assume whatever is doing it doesn't
> realize it's a command channel for an active FTP connection...then all
> they'd see is a inactive session.
>

You mean in the case of a NAT connection where a table of different TCP 
sessions needs to be maintained, and since the size of that table is 
limited, it makes sense to clean up old ones?  (That's what all of your 
links talk about.)

I guess in that circumstance, you might want to do as you describe.

In the dial-up situation that I described, though, it doesn't make sense 
to look at the individual sessions because your goal is to know whether 
the modem needs to be connected or not.  You don't care which TCP 
session requires the modem, as long as any of them need to send data, 
then you have to keep it open.  It doesn't matter which one is the 
control connection and which one is the data connection, as long as one 
of them is sending data, you don't disconnect the modem.

the NAT situation is an angle I had not thought of (I don't mean I've 
never thought about it -- just that I didn't think about it in regards 
to your particular issue.)

>
> My assumption is that you'd have to send the NOOP, wait for the reply
> to it before continuing the transfer.
>
> So threading would be contra-indicated.


But nothing in the FTP standards says that you can do this.  Are you 
certain that it'll work with all FTP servers?

The FTP standard says that the protocol works in alternating 
statement/response pairs.  So you send a command, then get a reply, then 
send another command, then get another reply, et al.

So you have something like:

NOOP
200 OK

or

CWD /home/scott
250 "/home/scott" is current directory.

In each case, the first line is a command sent by the client, and the 
second one is a response from the server.  Now, granted, STOR is a 
little different. It has more than one response...  but 1xx responses 
are never treated as 'final' responses.  So you'd have this:

STOR myfile
150 Sending file to "myfile"
226 Transfer complete

It's always a command sent, followed by it's response.  But you are 
proposing something very different that I suppose might work in some FTP 
servers, but isn't blessed by RFC 959, and probably won't work with all 
servers.  You are proposing this:

STOR myfile
150 Sending file "myfile"
NOOP
200 OK
NOOP
200 OK
NOOP
200 OK
226 Transfer complete

You see what I mean?  you are sending a new command (NOOP) in the MIDDLE 
of carrying out an existing command.  There's nothing in the FTP 
standards that allows that.  And none of the links you provide say that 
this is valid, either.  Indeed, one of the links you provided (the "indy 
ftp large files" one) has this in it's accepted answer:

     A lot of FTP clients will send NOOPs while everything is idle,
     but I don't know if any that send them during a data transfer
     because you would need to handle the responses in that case,
     and many servers won't send them back until the data is
     finished transferring.

That's pretty much exactly my objection.  Sure you can send a NOOP while 
things are idle...  but not *during* a transfer!  You always have to 
wait until one command is finished before you can send the next one (the 
exception being the ABOR command that aborts a transfer.)  You can't 
send a new command while an existing one is still being carried out.

>
> Ironically enough, when we started seeing the issue, I had a vague
> recollection of hearing about it before. And I would have sworn that
> you were the one I'd heard about it from!
>

I often think that I'm getting stupider as time goes by.  It's entirely 
possible that I was brilliant a few years ago, and am a complete idiot 
today.  Such is the price of getting older.

But, all of your links discuss setting up keepalives on the command 
channel, and NOT trying to use NOOP during a transfer.  I know that the 
dial-up modem situation I described earlier would ignore keep-alive 
packets (and so they would *not* keep the dial-up active.)  But perhaps 
they'll work in the NAT situation.

It'd be easy enough to try turning on keepalives to see if it would 
solve your problem, right?
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------