I’ve been through my code some more, and it appears that I only call wip_close() if there’s been an error and it’s time to clean up the mess. Otherwise, both my data and control handlers simply ignore (well, output a trace message) the WIP_CEV_CLOSE events. It appears from my code that both channels are closed by the time the finalizer is called - as all that is done in the finalizer is that memory associated with the transfer is released.
It’s been a while since I did this, but there’s something in the back of my mind that’s saying with a FTP wip_putFile(), only the write channel is opened, and calling wip_shutdown() marks the uploaded file as complete. There’s a one-line note in the API (section 7.4.2) for wip_putFile() that indicates that only possible event is WIP_CEV_WRITE. However, the wip_shutdown() doco (6.5.6) indicates that a WIP_CEV_PEER_CLOSE event is sent to the peer (server??) socket when the output comms is closed.
In my code, it appears that the WIP stack calls wip_close() internally after the contents of the wip write buffer have been uploaded, and then calls the finalizer after the internal wip_close() has completed.
As I said, it’s been a while since I’ve done this - all my own applications use HTTP post to a server rather than FTP - as I was having issues with proxies and firewalls etc when using FTP. Note that it’s important to use wip_shutdown() after finishing the write when doing a HTTP POST - otherwise you won’t get the return from the web server!!!
And it doesn’t help that the API docs are fairly sparse and the examples provided are simplistic at best.
Hopefully this will get you a bit closer…