Re: Non-blocking SSLWrite problems
Re: Non-blocking SSLWrite problems
- Subject: Re: Non-blocking SSLWrite problems
- From: Chris Newman <email@hidden>
- Date: Wed, 12 Oct 2005 12:32:49 -0700
I've hit the same problem using the Mozilla NSS APIs in asynchronous mode. The
problem is that SSL by its nature can not have the same semantics as a regular
socket API (so the name itself is misleading) because the crypto block data is
committed before it's possible to determine if the write will block.
To see an in depth discussion of the underlying technical problem and how it
might be solved, check out:
<https://bugzilla.mozilla.org/show_bug.cgi?id=80092>
Incidentally, it would not surprise me if the Secure Transport SSL APIs (and
perhaps even the OpenSSL APIs) have the same bug that NSS has in this area.
- Chris
Brian Webster wrote on 10/12/05 11:35 -0500:
In my program, I'm using the Secure Transport SSL APIs to send encrypted
data over a standard UNIX socket. I have separate threads for reading and
writing to the socket, and since SSLRead/SSLWrite aren't thread safe in this
manner, I've configured my socket to be non-blocking and put appropriate
locks around the read/write calls, using select to wake up a thread when the
socket is ready to read/write.
The problem I'm having occurs when I write a large enough chunk of data to
SSLWrite such that it fills the socket's outgoing buffer. This causes it to
give back an EAGAIN error code, which I then translate into returning
errSSLWouldBlock from my write callback, as the documentation says you
should do. The problem is that the value I'm getting back from the last
argument to SSLWrite, which passes back the number of bytes successfully
written to the stream, always returns the full number of bytes that were
given to SSLWrite, despite the fact that not all those bytes were actually
written to the socket. I've checked the value output through the dataLength
parameter in my SSLWriteFunc callback, and 0 is in fact being returned along
with my errSSLWouldBlock error code.
For example, say I call SSLWrite and pass in 91229 bytes of data. SSL
breaks this up into chunks for sending, so my callback gets a series of
calls writing out 16318 bytes of encrypted data (which is actually 16300
bytes of data plus an 18 byte SSL header). So I get 5 of these chunks, all
of which get written out fine, so I've written 16300 * 5 = 81500 bytes of
data. I then get the final chunk, 9747 bytes of encrypted data, and when I
try to send that, I get EAGAIN. I return errSSLWouldBlock and 0 for the
dataLength, but when SSLWrite returns, it says it wrote 91229 bytes of data,
when in fact only 81500 bytes were written.
Stepping through in the debugger, I also discovered that if I break on my
callback on the very _first_ chunk of data that is written and go back up
the stack to where I call SSLWrite, the output parameter for the number of
bytes sent has already been filled in with the value 91229! When it hasn't
even written a single byte to the socket yet! It seems like SSLWrite is
just completely ignoring the dataLength value I'm passing back from my
callback.
So, first I'd like to make sure I'm not missing something totally obvious
and expecting the wrong thing here, or if this is a bug in the SSLWrite
function. I'm also wondering if anyone else has encountered a similar
problem and was able to find a workaround for it.
--
Brian Webster
email@hidden
http://homepage.mac.com/bwebster/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
om
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden