Re: FTPAPI connection reset

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

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.

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.)

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.

Nobody else has reported a problem like this.  Not sure where to go with 
this...?


On 3/1/2012 9:33 AM, Charles Wilt wrote:
> Upon further review...
>
> I don't believe the socket reset is being thrown at the FTP_quit() call..
>
> Instead, I think it is coming here in ftp_putraw() when the Reply()
> procedure is called after put_block() completes...
>
>        * note that we don't do "line mode" for a put.
>        *   it'd be kinda pointless, since we're not reading
>        *   the results...  plus, all it would be is a custom read proc...
>   B01 c                   if        put_block(wwSock: peDescr: peReadProc)<0
>       c                   return    -1
>   E01 c                   endif
>
>        * 226 Transfer Complete.
>       c                   eval      wwReply = Reply(peSocket: wwMsg)
>
>
> Assuming this is correct, quietly swallowing there error in our code
> is not an option.
>
> I suppose we might be able to do so somewhere in the above FTPAPI
> code.  But that doesn't seem like a good idea.
>
> Instead, i think the only real answer is to modify put_block() to
> periodically send something out the command channel..
>
> Thoughts?
>
> Charles
>
> On Thu, Mar 1, 2012 at 9:28 AM, Charles Wilt<charles.wilt@xxxxxxxxx>  wrote:
>> We are using FTPAPI to transfer files to a WebMethods Integration Server...
>>
>> Once and a while, we'll see an exception thrown: "A connection with a
>> remote socket was reset by that socket"
>>
>> It appears to occur after the data transfer completes, the file is
>> intact at the destination, when our RPG program calls the FTP_Quit
>> procedure.
>>
>> Given that the file transfer takes 5+ min, I'm assuming the command
>> channel connection is being closed by the remote machine due to
>> inactivity...from what I'm been able to find about FTP in general,
>> this is not an unknown problem.
>>
>> Has anybody run into this?
>>
>> The question, assuming we can't ask the Webmethod guys to increase
>> their timeout, how can we handle this on our side?
>>
>> My research has shown that at least a few FTP clients handle this by
>> using a "keep-alive"; periodically issuing a command such as SITE over
>> the command channel while the data transfer is going on.  I'm thinking
>> the FTPAPI put_block() procedure could be modified to do this...
>>
>> Otherwise, I supposed we could just quietly swallow the error...as it
>> doesn't really matter.
>>
>> Thoughts?
>>
>> Thanks!
>> Charles
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>

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