[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FTPAPI Timed out after large number of PUTs
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
-----------------------------------------------------------------------