we currently run into the same issue in a large batch job and our system is on V7R1.
Did you put the ftp_killSock() function into a new release of the FTPAPI? I would like to use it too.
Thanks in advance.
scottklement.com[mailto:ftpapi-bounces@lists. scottklement.com] Im Auftrag von Bradley Stone
Gesendet: Freitag, 21. April 2017 20:13
An: FTPAPI/HTTPAPI mailing list <ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Betreff: Re: [Ftpapi] FTP API not closing socket after sending data?
Well not sure if anyone cares, but I was able to "fix" this issue by updating FTPAPI... I added an ftp_killSock() function that runs an ENDTCPCNN command on the connection when it's done.
I think I also found why this was a bug in this OS version.. the getsockname() function was returning the remote IP instead of the local IP... (at least the local port was correct!) So you'd never be able to use the data returned from it to close the connection. so I did what anyone would do.. I hardcoded it. ;)
Anyhow, thanks again for your help Scott.
On Thu, Apr 20, 2017 at 6:45 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:
Ok, I have verified it must be an OS bug on V5R4. It must be. V7R3 things work just fine.
Sorry to bother.. I should have checked that out first... now I need to figure out how to solve this issue. :) I wonder if a normal FTP session will do the same thing... ugh.. :)
On Thu, Apr 20, 2017 at 5:04 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:
I just did a test that FTPs two files (each one separately.. open, put, close... open, put, close).
The ftp-conn ended right after the close, but the ftp-data sockets look open?
10.10.10.213 ftp-data 18855 000:00:16 Time-wait
10.10.10.213 ftp-data 41045 000:00:16 Time-wait
... and then later...
10.10.10.213 ftp-data 18855 000:02:02 Time-wait
10.10.10.213 ftp-data 41045 000:02:02 Time-wait
As you can see, the idle time keeps going up, even though everything is done. They seemed to end shortly after the 2 minute mark.
from the web:
TIME_WAIT The socket is waiting after close to handle packets still in the network.
Not sure what it would be waiting for. It does appear to finally end after some sort of time out.
These are small files, and they actually get sent to a PC as TIFF images to get redacted. Once done, the PC places them in the IFS for me to work with. The redaction finishes before these sockets close, so it shouldn't be waiting for data.
It could be an OS bug, though. This customer is on V5R4 and didn't keep up on PTFs very well. They do plan on moving to V7Rx shortly since the SSL portion of the project requires that.
I will also test on my V7R3 machine.
On Thu, Apr 20, 2017 at 4:52 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:
I see that too now, Scott. Hmm.. I'll do some more digging and let you know what I find.
I really only dug into this because the ftp_conn() starting failing with a -1 while testing. (No description of the error either, but I'm sure there's something in there that lets be get the errno and description I would think).
Anyhow, I'll update with more info when I find it. Thanks, Scott.
On Thu, Apr 20, 2017 at 3:16 PM, Scott Klement <sk@xxxxxxxxxxxxxxxx> wrote:
The socket should actually be closed in the put_block() routine. I can see the code that does callp close() at the end of this routine (just before it returns at the very end). It should always close this socket -- I can't see any way that it'd get out of the put_block() routine without closing it.
This does not mean that the socket would disappear from netstat immediately. When FTPAPI writes the last data to the socket, it immediately closes it and returns control to your program. In the background, the OS may still be sending the data over the network. At this point, the status should change from "Established" to either "Fin-Wait-X" or "Close-Wait". So this might be what you're seeing -- the data connection appears to be still open, but it's actually closed, but the OS still has more work to do in the background. Could that be what you're seeing?
If it still says "Established", however, then there is likely a bug somewhere. In that case, I'll need to know exactly how to reproduce it.
On 4/20/2017 2:29 PM, Bradley Stone wrote:
I only traced ftp_putraw() in debug from the ftp_put() that I am using. This in a sense all my application does:
sess = ftp_conn(ip:user:pw);
On connect I see one ftp job in netstat open.
On ftp_put() I see a second socket opened for data.
On ftp_quit() I see the first socket close, but the one created from ftp_put() stays open and eventually does time out and end after a minute or 2 (I didn't time it exactly).
I hope this helps! I mean, I know I can go in and updated it, but I wanted to make sure I'm not doing something wrong on my end.
Bradley V. Stone
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail, or any Cloud Provider!
On Thu, Apr 20, 2017 at 2:19 PM, Scott Klement <sk@xxxxxxxxxxxxxxxx <mailto:sk@xxxxxxxxxxxxxxxx>> wrote:
Does this happen with calls to ftp_put()? Or Just ftp_putraw()?
It's been a long time since I've looked at FTPAPI (I don't need it
for work these days) so the more specific info you can provide,
On 4/19/2017 11:37 AM, Bradley Stone wrote:
FTP API beta version 3.0
I started using FTP API for a client and so far it works great
except for one thing... after a STOR it seems to leave the
data socket open.
Because we're sending a lot of files this eventually ends up
with the system not being able to create more sockets (too
many open) and the following FTP commands aren't run until the
sockets eventually timeout.
In debugging I see that the call to FTP_putraw() opens wwSock
but it's only closed if there is an error.
I could be missing something here. :)
Bradley V. Stone
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail,
or any Cloud Provider!
Ftpapi mailing list
Ftpapi mailing list
-- _______________________________________________ Ftpapi mailing list Ftpapi@xxxxxxxxxxxxxxxxxxxxxx http://scottklement.com/mailman/listinfo/ftpapi