Re: PR_IO_TIMEOUT_ERROR when doing a PR_Send with PR_INTERVAL_NO_TIMEOUT???

2001-10-24 Thread Mike Oliver

- 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






Re: PR_IO_TIMEOUT_ERROR when doing a PR_Send with PR_INTERVAL_NO_TIMEOUT???

2001-10-23 Thread Nelson B. Bolyard

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?

--
Nelson Bolyard   Netscape 
Disclaimer:  I speak for myself, not for Netscape




Re: PR_IO_TIMEOUT_ERROR when doing a PR_Send with PR_INTERVAL_NO_TIMEOUT???

2001-10-23 Thread Mike Oliver

No, I have not set SSL_ENABLE_FDX. W/r/t options, all I have set is:

SSL_SECURITY
SSL_HANDSHAKE_AS_CLIENT

Mike Oliver
Invertix

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?

 --
 Nelson Bolyard   Netscape
 Disclaimer:  I speak for myself, not for Netscape






Re: PR_IO_TIMEOUT_ERROR when doing a PR_Send with PR_INTERVAL_NO_TIMEOUT???

2001-10-23 Thread Nelson B. Bolyard

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




PR_IO_TIMEOUT_ERROR when doing a PR_Send with PR_INTERVAL_NO_TIMEOUT???

2001-10-22 Thread Mike Oliver

What does it mean when I get a PR_IO_TIMEOUT_ERROR error when I do a PR_Send
with PR_INTERVAL_NO_TIMEOUT? Shouldn't the call wait forever? I'm using
non-blocking sockets over an SSL connection. This happens randomly.

Thanks in advance.

Mike Oliver
Invertix






Re: PR_IO_TIMEOUT_ERROR when doing a PR_Send with PR_INTERVAL_NO_TIMEOUT???

2001-10-22 Thread Mike Oliver

I apologize, but I actually mis-typed. I'm using BLOCKING sockets over an
SSL connection... Does this make any sense now?

Mike Oliver
Invertix


Wan-Teh Chang [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 Mike Oliver wrote:

  What does it mean when I get a PR_IO_TIMEOUT_ERROR error when I do a
PR_Send
  with PR_INTERVAL_NO_TIMEOUT? Shouldn't the call wait forever? I'm
using
  non-blocking sockets over an SSL connection. This happens randomly.


 For non-blocking sockets, the 'timeout' argument to NSPR
 I/O functions is ignored.

 Calls on non-blocking sockets do not wait forever, and
 they should not fail with the PR_IO_TIMEOUT_ERROR error
 either.  What you reported is a bug.

 Wan-Teh







Re: PR_IO_TIMEOUT_ERROR when doing a PR_Send with PR_INTERVAL_NO_TIMEOUT???

2001-10-22 Thread Wan-Teh Chang

Mike Oliver wrote:

 I apologize, but I actually mis-typed. I'm using BLOCKING sockets over an
 SSL connection... Does this make any sense now?


It's still a bug for PR_Send() with PR_IO_NO_TIMEOUT on
blocking sockets to fail with the PR_IO_TIMEOUT_ERROR error.

Wan-Teh