Re: FTPAPI connection reset

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Hi Scott,

comments inline...

On Thu, Mar 1, 2012 at 2:15 PM, Scott Klement <sk@xxxxxxxxxxxxxxxx> wrote:
> Hi Charles,
>
> I don't agree with your analysis.  The FTP server is supposed to keep
> the command channel open until the file transfer completes so it can
> send a '226 Transfer Complete' message.  This message is the only thing
> that tells us that the transfer completed successfully.

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.

>
> Furthermore, "Connection Reset" isn't a 'normal' disconnect.  It implies
> that there's an error somewhere. Most likely, that some data was sent,
> but the other side didn't receive it.  "Connection Reset" is a TCP error
> (not an FTP error) so it pertains specifically to the socket you're
> getting the error on (not to the FTP transaction as a whole, which is
> conducted in multiple sockets.)

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

>
> So if you're getting a "connection reset" on the reply() procedure...
> err, well... reply() doesn't send any data.  It only receives data.  So
> a prior send (the STOR command?) sent some data that was not received by
> the remote host.  A very strange situation indeed.

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

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

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?

Again, I'm thinking out loud...my socket programming skills are very rusty :)

If the problem occurred on the data channel during the file transfer,
I would have expect to see more in the log than just
0: > STOR
OnlineBillPay_FileTransfer~mam_ref_543471.120228.pgp;application:cintasFTP
0: 150 Binary mode data connection for
OnlineBillPay_FileTransfer~mam_ref_543471.120228.pgp;application:cintasFTP
(10.20.117.1,15511).
0: > QUIT

Our code looks like:
// Send file.
if FTP_put(Sess : RmtFileName : LclFileName) < 0;
  ReturnMsg = FTPError(Sess : ReturnCode);
  exsr EndPgm;
endif;

// End program.
exsr EndPgm;

begsr EndPgm;
  if Sess >= 0;
    FTP_quit(Sess);
  endif;
  endif;
  *inlr = *on;
  return;
endsr;

So I all know is that
1)  FTP_put returns < 0, ReturnMsg is "A connection with a remote
socket was reset by that socket"
2) The file is complete on the destination server...

Given #2, I'm assuming that put_block() is completing normally.  But I
don't know.  Perhaps my first step should be to enhance logging so
that I know for sure where and on what socket the problem is
occurring.

Charles
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------