So far, I have managed to grab a copy of WIP library version 3.00.21 from SDK 3.15.
My SMTP code compiles OK and runs. wip_SMTPClientCreate does not return NULL and most of the time session channel’s handler gets WIP_CEV_OPEN within just seconds.
Most of the time, but not always. Sometimes the WIP_CEV_OPEN cannot be seen for quite a long time (hours!) for no reason. In fact, no events can be seen at session channel’s handler at all.
Do I have to write additional timer code to track this type of behaviour (which I can’t think to be the right one) and to kill the successfully created session channel if there has been no events in its handler for, say, a couple of minutes?
It is always wise to include your own protection against anomalies such as this!
I haven’t used the WIP SMTP, but I have certainly seen anomalous behaviour in other areas - so I would certainly recommend that you should definitely provide your own timeouts, etc…
No awneil, I have never heard of defensive programming. I understand it is important to make the code as failproof as possible, but to what extent?
I could’ve end up duplicating the whole ADL/WIP functionality - just how much sense would it make?
One of major reasons I’m using OpenAT platform is that it is a great time- and effort saver. No need to write your own AT commands and responses code, no spending time on studying through TCP/IP RFCs to run sockets or high level things like HTTP or SMTP; just grab and go. Speaking socket-wise, I would expect the appropriate handler to react somehow when I am trying to open it - either with success or with error (and timeouts of all sorts could be treated as errors, too). Why dealing with hi-level connections must be different?