Re: Non-blocking SSLWrite problems
Re: Non-blocking SSLWrite problems
- Subject: Re: Non-blocking SSLWrite problems
- From: Brian Webster <email@hidden>
- Date: Wed, 12 Oct 2005 17:46:11 -0500
On Oct 12, 2005, at 4:25 PM, Frederick Cheung wrote:
On 10/12/05, Brian Webster <email@hidden> wrote:
On Oct 12, 2005, at 12:08 PM, Rich Siegel wrote:
As far as I know, the SSLWriteProc should never return
errSSLWouldBlock,
and in fact none of mine ever do. Your SSLWriteProc should push the
data
at the socket, set *dataLength to the actual amount of data that was
actually transmitted, and only return an error if you want the whole
process to abort.
The way the docs are written implies that you should be able to
return errSSLWouldBlock. From the discussion of the SSLWriteFunc
callback:
I've certainly done this in my ssl write funcs without any problems.
I'm curious, after you have returned errSSLWouldBlock (and SSLWrite
has returned) does SecureTransport call your SSLWriteProc again with
the remainder of the data?
It does not call the callback again after returning errSSLWouldBlock.
However, I did a little more testing, and here's what appears to be
happening. I get back the full number of bytes as being written from
the SSLWrite call, but only part of it has actually gone out the
socket. But, if I let me program continue and send the next message
(which I hadn't before, since I was stopping at the breakpoint and
gawking at the return values), then it appears that SSL still has the
unwritten encrypted data sitting around in its cache, and it pushes
the rest of that data out the socket before writing the next chunk of
data.
So it looks like a second call to SSLWrite needs to be made to
trigger pushing out the rest of the data. I already call select()
with my socket descriptor to block until the socket is ready for more
data when I get errSSLWouldBlock returned, so I think I may try
looping around and calling a zero length SSLWrite after select()
returns and see if that forces the rest of the data through. Most of
the time the rest of the data gets pushed through by the next message
I'm writing out to the socket, but of course this wouldn't work if
the last message in a series were the one to fill up the buffer.
--
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