It looks like that there is no way to know when the wip_write() function successfully completes a write cycle, is there?
If wip_write() has data sent to it that is not as long as the send emission buffer, then the WIP_CEV_WRITE event is never received upon completion of the write instance. This leaves the channel open indefinitely until the peer closes or the channel times-out, where upon the WIP_CEV_PEER_CLOSE, or WIP_CEV_ERROR events occur allowing for a wip_shutdown, and finally wip_close to be used?
Other than spawning a new channel for every communication event between client(ME)/server, is there a way one channel can be opened and used for multiple communication purpose and still have concise separation between consecutive writes to the channel?
I had the same problem. My current solution is to wait 10 seconds after sending the last bytes and then I call wip_close(). So the most files was received well on the FTP server but the server does recognize a time out.
The solution mentioned from the wavecom support is using wip_shutdown() instead of wip_close(). If I do this I receive an WIP_CEV_PEER_CLOSE event after a while. Unfortunately I get a memory release error if I’m close the channel using wip_close() then. If I don’t close the channel my system can only send 6 files. If it will send the seventh file it get no free handle.
Does some one have an idea how to solve this problem?
You can close (or shutdown) immediately after your last write, the library will only perform the actual socket closure once the last data has been sent and acknowledged. That’s the way POSIX OSes work, by the way, as you can check with a netstat.
The only synchronization problem you might have is with bearers: if you close a bearer, it closes even if there are pending data on some sockets, so you might interrupt some connection. That’s where the shutdown trick is useful: if you shutdown the connection on your side, the peer will shutdown in return when it receives your shutdown (i.e. when it has read everything you had to send). You’ll therefore receive a WIP_CEV_PEER_CLOSE: then it’s safe to completely wip_close() the socket. So you can:
wip_close() the socket
maybe allow a small timer delay (socket closing is done asynchronously, to avoid resource denials in your event handlers, I’m not sure whether it’s taken care of by wip_bearerStop()).