[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FTPAPI connection reset
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
-----------------------------------------------------------------------