Non-blocking SSLWrite problems
Non-blocking SSLWrite problems
- Subject: Non-blocking SSLWrite problems
- From: Brian Webster <email@hidden>
- Date: Wed, 12 Oct 2005 11:35:45 -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:
This email sent to email@hidden