On 11/25/2010 5:54 PM, passfree wrote:
Hi list,
I am developing a XPCOM component to wrap input/output stream pairs
into ssl for server or client communication. I am not familiar with
NSS and I don't know how to write proper xpcom components in C but I
have a working implementation.
I have one problem though. I do not know how to deal with non-blocking
input and output streams. If I create a blocking stream the handshake
and everything else works just fine. However, if I am working in non-
blocking mode, my PRFileDesc IO layer recv function could fail with
PR_WOULD_BLOCK_ERROR upon which the NSS fails as well. I am not sure
how NSS works in nonblocking mode.
When a recv (or send) implementation of a NSPR socket returns
PR_WOULD_BLOCK_ERROR, the upper level (caller) is responsible for
polling the socket for read (or write) ready state and then, when the
state has been signaled, simply call recv (or send) again with the same
argments, see PR_Poll for more information. PR_WOULD_BLOCK_ERROR means
the operation cannot be completed right at the moment (e.g. there are
not yet any data to read from the socket/stream or the send buffer is
full and we have to wait for data be physically send from the buffer to
the network to free the output buffer). The read (or write) ready state
signal gives us the information we have a data to read (or space to send
a data). Also, signaling e.g. the read ready state doesn't necessarily
mean that the following call to recv must not again return
PR_WOULD_BLOCK_ERROR. For instance, SSL socket implementation from NSS
will return PR_WOULD_BLOCK_ERROR 2 or 3 times during an initial
handshake even you got 2 or 3 times read ready state from PR_Poll ; it
is used to process the SSL handshake in a non-blocking way.
However, if I understand correctly, you are concerned just about your
NSPR socket implementation is correct, right? It looks ok to me, though
I am not sure what is the implementation of the stream you are accessing
through secret->sslPipe->(input|output)Stream.
Just a detail: in condition data->value.non_blocking =
isInputNonBlocking && isOutputNonBlocking you should be using ||
instead. Or better, ensure that both input and output stream are in the
same setting for blocking (both block or both don't block).
-hb-
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
