On 2/20/2012 2:52 PM, maddy wrote:
Hi,
first: ssl thread has been removed recently (bug 674147). That change
is currently in Firefox Beta (11), so you should update and test your
extension/code with Firefox Beta code base.
second: we do not support blocking sockets being accessed on the socket
transport (a.k.a. network) thread. If you are accessing your blocking
socket on, e.g., the main thread, then things will work for you. If you
are accessing your blocking socket on the socket thread, then things
will break -> don't do that.
The standard way of implementing a socket is to be non-blocking.
Another argument for it is that we may probably soon stop support for
blocking sockets at all, but that is speculative now.
-hb-
While doing SSL handshake my code returns the "Data transfer
interrupted" error. I must say that the socket library that I have
doesn't have a non blocking recv.
What I observed with the SSL trace logs from my Windows code is as
follows:
1. Socket thread keeps sending GET requests
2. nsSSLThread actually sends out the GET request only when the SSL
handshake is done
3. Since the windows socket recv is a non blocking call, he returns -1
many a time i.e. the PR_WOULD_BLOCK_ERROR. This ensures that the
nsSSLThread::Run is able to move it's state machine from
ssl_pending_read to ssl_pending_reading_done to ssl_idle.
4. This non blocking recv return -1 scenario ensures that the socket
transport thread actually suceeds in writing the GET request to the
ssl pending buffer.
Now coming to my scenario:
Since my recv is a blocking call and SSL sets a timeout of 0xFFFFFFFF
i.e. wait forever, my recv blocks until some data is received. Now
what I see in my logs is
1. Socket thread cannot send the GET request as nssslThread::
ssl_state is always ssl_pending_read
2. nsSSLThread::Run -> PRInt32 bytesRead = realFileDesc->methods
->read(realFileDesc,
bstd.mSSLDataBuffer,
bstd.mSSLRequestedTransferAmount); -> ssl_SecureRecv
-> ssl_Do1stHandshake is running and doing its job for a long time. (I
see that in windows it fails as the non blocking recv keeps throwing
would block error)
3. Socket gets closed from the server side and I get "Data transfer
interrupted" error.
What I want to know is should I fine tune my recv and make it return
the would block error now and then so that the Socket transport still
suceeds in posting it's GET request to the pending buffer?
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
