Thanks for your patience. But, this is what I'm trying to say. I know that PR_Read will always block until complete if it's a blocking socket.
If I were working w/ Win32 sockets or Berkley sockets directly, I could call: ioctrlsocket (WinSock) or ioctl (Berkley) on the socket to determine the amount of data that needs to be read, if any. That way, I know that when I call recv, even though it will block, it will return in a finite amount of time because there is data in the socket to be read. So - is there an NSPR equivalent of ioctrlsocket or ioctl? I thought it would be PR_Poll or PR_Available, but I was wrong. Separately, assuming that there isn't an alternative above, I'll have to use non-blocking sockets. What is the correct way of doing a PR_Read and PR_Write with non-blocking sockets? When I switch to using PR_Read w/ a non-blocking socket, it doesn't seem to clear to socket, I get the same data over and over again. One last question: What's the difference between PR_Read/PR_Write and PR_Recv/PR_Send when working w/ a socket? Sorry for the basic questions - thanks in advance. Mike Oliver Invertix "John Gardiner Myers" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > Mike Oliver wrote: > > That doesn't make sense to me. With blocking sockets, you still should be > > able to query the socket first for data before doing the actual blocking > > read > > That is not the case. If you don't want to block, make the socket > nonblocking. I don't know how I can make this concept simpler. > > > - Also, I noticed that PR_Available returns a NOT_IMPLEMENTED error code - > > anyone know about that? (using latest NSPR release) > > The SSL code indeed does not implement the "available" operation. The > SSL code cannot tell how much data it can return to the caller until it > has read and decoded an entire SSL record from the lower layer socket. > > > - SSL_DataPending seems to return 0 always regards of blocking/non-blocking. > > SSL_DataPending returns the amount of data buffered in the SSL layer > itself. In order to be nonzero, a previous read operation would have > had to decode an SSL record that had more data than could be returned to > the caller.
