Re: FTPAPI Timed out after large number of PUTs

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>


> The program below also uses Toms BASICS1 and IFS  service programs for
> directory and file manipulation.

I'm not familiar with this "BASICS1 and IFS service program".  You'll need 
to contact Tom (Tom who?) if you need help with that.


> The program would hang after transferring 300 (not always the same number)
> or more files successfully so I added the 15 second socket timeout.

It's likely that the server is disconnecting you for inactivity on the 
control connection.  In FTP, there is one connection where commands are 
submitted, called the control connection, and other connection is made for 
each file that's transferred.

If the server has a 5 minute timeout, and it takes longer than 5 minutes 
to download/upload a file, it might timeout and disconnect you because of 
inactivity on the control connection while the file itself is 
transferring.

Granted, it SHOULDN'T do that... but it might.  I know that many of the 
FTP servers did that at one time.


> The program regains control but does not recover after the quit and connect,
> It cannot reconnect so it ends.
>
> This transfer is AS/400 to AS/400 internet speed probably 128k or less.

What do you mean by "does not recover"?


> My theory is that some ISP along the way is not seeing traffic on port 80
> thinks it is inactive and closes the connection.

Doesn't make sense. There's no "connection" as far as the ISP's routers 
are concerned. All of the data from your communications session is broken 
into datagrams ("packets") which are sent one at a time through the 
various routers. When the channel is "inactive" it means that no packets 
are being sent.  AT that point, the ISP sees nothing at all from you, so 
it doesn't know that there's anything to disconnect.

Unless you're saying that a modem is being disconnected?  I would HOPE 
that an ISP doesn't think that port 80 traffic (HTTP/WWW) isn't the only 
traffic that counts towards activity/inactivity!

I'm guessing (by the 128k) that you're using ISDN. Dial-up communications 
are a fickle thing. There's a lot that can go wrong. It makes sense to 
have code that detects a failure and restarts everything.


> Weather my theory is correct or not how can I get the program to recognize
> the connection is lost establish a new one and just continue on???

Depends on why it's not recovering?


> > STOR /lcm/CTY74_20050211_112225392_1764.xml
>
> DSPLY  Timed out while waiting for data from socket            **********
> connection times out
>
> > QUIT
>
> 150 Sending file to /lcm/CTY74_20050211_112225392_1764.xml

You get this after the "QUIT" message?!  That means that something is out 
of sync. You should be receiving this after the STOR message, not after 
the QUIT message...


> 220-QTCP at WEB4002.xxxxxxxx.COM.
>
> 220 Connection will close if idle more than 5 minutes.
>
> > USER webxxxxx
>
> DSPLY  Timed out while waiting for data from socket

This looks like it reconnected successfully (the 220 lines mean that it 
has reconnected) but the server isn't letting you sign-in (timeout from 
the USER subcommand)  Of course there's a very similar problem where 
you're getting a timeout on the STOR command, only to get it's response 
when you run the QUIT command.

My best guess at this point is that the connection is very slow.  Too 
slow, in fact, for a 15 second timeout. FTPAPI is sending the STOR 
command, and timing out before it receives the 150 response.  Then it 
issues the QUIT command, but within the 15 second response time for that 
command, it finally gets the response from the STOR command...

Try making your timeout larger instead of smaller.

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------