- Platform is Win2K/Win32 - Acting as a client - Blocking SSL Sockets Your speculation seems to make sense because I only get PR_INTERVAL_NO_TIMEOUT with the first call to PR_Send _sometimes_. And, if I happen to step through the socket creation/SSL handshake process w/ the debugger and then just run when the creation process is done, I never get this problem. So, it seems that one of the initialization functions says it's done, when it's not quite done, I would guess. Could I use PR_Poll in this case to ensure that the SSL socket is ready, 100% garaunteed??
Mike "Nelson B. Bolyard" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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
