Mike Oliver wrote: > > "Nelson B. Bolyard" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > This can happen if you have set the SSL_ENABLE_FDX flag on the SSL > > socket, but do not have threads reading and writing simultaneously. > > > > Have you set SSL_ENABLE_FDX? > > No, I have not set SSL_ENABLE_FDX. W/r/t options, all I have set is: > > SSL_SECURITY > SSL_HANDSHAKE_AS_CLIENT
More questions: 1. What platform? 2. Is your program acting as an SSL server at any time? (The HANDSHAKE_AS_CLIENT would suggest not, but I have to ask) One way it could conceivably happen is as follows: SSL or NSPR might call some system function, other than send or recv, that normally does not block for a long time, but that is capable of retunring ETIMEDOUT (if Unix) or WSAETIMEDOUT (if Win32). The PR_INTERVAL_NO_TIMEOUT timeout value should prevent the underlying system send or recv call from returning ETIMEDOUT, but some other system call could unexpectedly return it, causing NSPR/NSS to return it as PR_IO_TIMEOUT_ERROR. This is just speculation, of course. Please continue to post any followup messages to this newsgroup. -- Nelson Bolyard Netscape Disclaimer: I speak for myself, not for Netscape
