Re: Non-blocking SSLWrite problems
Re: Non-blocking SSLWrite problems
- Subject: Re: Non-blocking SSLWrite problems
- From: Ladd Van Tol <email@hidden>
- Date: Wed, 12 Oct 2005 09:55:23 -0700
Not sure about SecureTransport -- I used the OpenSSL API directly
when I was doing this, and had no problems with having separate read
and write threads.
Also, SecureTransport may be thread-safe and possible to use in
blocking mode. See:
http://lists.apple.com/archives/Macnetworkprog/2003/Jul/msg00037.html
- Ladd
On Oct 12, 2005, at 9:35 AM, Brian Webster wrote:
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:
40criticalpath.com
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