The only way I could get the Ssl routines to communicate at all with my server was to set the netSocketOptSockNonBlocking _after_ the SslOpen handshake, and keep it set thereafter. Any other changes to that flag in the socket would cause the Ssl commands to simply hang.
But with that socket option set, SslOpen succeeds, it proceeds to do an SslSend to send a POST command, and then does an SslRead, which seems to read the complete server response, but also sets the SslContext error to netErrWouldBlock, killing the conversation. Setting the Context's ReadStreaming or not doesn't affect the outcome.
Trying to learn something from the socket or SslContext didn't give any clues. I tried to do a couple NetLibSocketOptionGet for any socket error and to check the blocking status thoughout the app, but they always return netErrUnimplemented (even though the docs say they are implemented). I also looked at most of the SslContext attribs, and didn't see any alarming changes to the SslContext from before to after the SslRead (I see a few changes in the SslSession.sessionid and SslSession.mastersecret, but I don't know if that should be alarming).
Jason
Hi Jason (and others),
I am trying to add SSL to my application. However, I run into exactly the same problem you have described.
I also found that SslRead() will never return, unless I set the socket to non-blocking. After I set the socket to nonblocking after SslOpen() returns, I perform a SslWrite() and then a SslRead(). Both seem to work fine. But then when I perform SslWrite() again, it always return -1 with the error code, netErrWouldBlock.
Have you found a fix to the problem you have described?
Does anyone else have any idea? Thank you very much!
Best Regards, Tony Cheung
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
